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(at)postgresql(dot)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(at)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