Re: Moving to git
От | Maciek Sakrejda |
---|---|
Тема | Re: Moving to git |
Дата | |
Msg-id | CAH_hXRZky_w9LoHV6ytFQY2K7F65h+c2GKZu7rMxS_DcTora3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Moving to git (Kjetil <polpot78@gmail.com>) |
Ответы |
Re: Moving to git
|
Список | pgsql-jdbc |
Verified that this works, and that the (filtered) diffs are clean for all tags. I've incorporated the script changes and pushed them out to the github repository I sent out earlier. I don't quite get the filtering expression here--can someone clarify? diff -r --exclude=CVS --exclude=.git . ../cvs-co/${tag} \ | grep "\$Header:" -v \ | egrep -v "^\-\-\-$" \ | egrep -v "^[0-9]+c[0-9]+" \ | grep -v "^diff \-r '\-\-exclude" Is this just filtering out the '$Header' in the Makefile from back in the day? Is there a better way to deal with this? It seems to get expanded to include my username and path to export. I'm fairly certain that with a judicious application of git filter-branch, I can strip out all those "manufactured commits" that Tom mentioned. The issues Kris mentioned [1] seem to be more complex, but I don't quite understand what they are. Can someone point out a specific bit of history that's mangled in Marko's github repo? I *think* it might be something like the problems discussed starting here [2] for the server migration, but it'd be helpful to see this going wrong in the jdbc history. Also, from reading the mailing list archives, it looks like tag-by-tag verification may *not* be a good way to verify sanity of full history. Any suggestions as to what a more extensive automated verification method might entail? We'd want to do manual spot-checks as well, of course, but is there something more we can do for an automated check? [1]: http://archives.postgresql.org/pgsql-www/2008-12/msg00124.php [2]: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01274.php --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
В списке pgsql-jdbc по дате отправления: