Re: git: uh-oh

Robert Haas wrote:
> This series of commits also seems pretty messed up:
> 
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00222.php
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00223.php
> 
> The commit messages make it clear that CVS did something funky,
> although it's not exactly clear retrospectively what it was.  At any
> rate, it's evidently still not right, because in the converted
> repository we get a whole slough of commits like this:
> 
> commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb
> Author: PostgreSQL Daemon <webmaster@postgresql.org>
> Date:   Sat Dec 2 08:36:42 2006 +0000
> 
>     This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'.
> 
>     Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon <webmaster@post
>     Delete:
>         src/backend/parser/gram.c
>         src/interfaces/ecpg/preproc/pgc.c
>         src/interfaces/ecpg/preproc/preproc.c
> 
> There are similar (but separate) commits for tag REL8_2_RC1,
> REL8_2_BETA3, REL8_2_BETA2, REL8_2_BETA1, REL8_1_STABLE, REL8_1_0_RC1,
> REL8_1_0BETA4, REL8_1_0BETA3, REL8_1_0BETA2, REL8_1_0BETA1, REL8_0_0,
> REL8_0_0RC5, REL8_0_0RC4, REL8_0_0RC3, REL8_0_0RC2, REL8_0_0RC1,
> REL8_0_0BETA5, REL8_0_0BETA4, REL8_0_0BETA3, REL8_0_0BETA2,
> REL8_0_0BETA1, REL7_4_STABLE, REL7_4_BETA5, REL7_4_BETA4,
> REL7_4_BETA3, REL7_4_BETA2, REL7_4_BETA1, REL7_2_STABLE, REL7_2,
> REL7_2_RC2, REL7_2_RC1, REL7_2_BETA5, REL7_2_BETA4, REL7_2_BETA3,
> REL7_2_BETA2, REL7_2_BETA1, REL7_1_STABLE, REL7_1_BETA3, REL7_1_BETA2,
> REL7_0_PATCHES, REL7_0, REL6_5_PATCHES, and release-6-3.  That's
> pretty crazy.  I think we should try to do something to clean this up,
> perhaps by doctoring the file on the CVS side.

This is probably caused by cvs2svn's failure to consider file deletions
when choosing the best revision from which to branch [1].  It would be
better to branch all of these symbols from the commit *after* the files
were deleted, which would make them all exact copies of the original
(rather than requiring a fixup branch).

I don't think that this can be fixed by doctoring the CVS repository (at
least, not short of removing the three files from the entire project
history).  It could be fixed post-conversion by using grafts, or by
shifting the tags and rebasing the branches.

I must say, it is refreshing to have users who actually care about their
conversion, as opposed to the usual rabble who think that git-cvsimport
is Just Fine :-)  I guess if the postgresql project didn't care about
data integrity then we would all have to worry :-)

Michael

[1] http://cvs2svn.tigris.org/issues/show_bug.cgi?id=55