Re: git: uh-oh

I wrote:
> OK, so I tried a conversion with the it.po hack I showed before; not
> trying to fix any of the other instances yet, but just see what happens
> with the 8.4.3/8.4.4 case. It's definitely better:

> * Marc's 8.4.3 tag commit is now the last ancestor of REL8_4_3, and the
> previous commits in the branch are earlier ancestors. No more 8.4.3
> as a stub branch.

> * it.po is shown as added, not modified, in Peter's 8.4-branch commit
> of 2010-05-13.

> * The cherrypick additions of xml2.out and xml2.sql no longer reference
> it.po too.

> But we're not quite there yet. What I find for it.po is these two
> commits, which immediately follow the addition of it.po on the main
> branch:

> commit fd0c9e8bbf50f65a6d03a5d5d59e19cf67c7bc94 refs/tags/REL8_4_3
> Author: Peter Eisentraut <peter_e(at)gmx(dot)net>
> Date: Fri Feb 19 00:40:07 2010 +0000

> log addition on branch

> D src/bin/pg_dump/po/it.po

> commit f345298286359f666211c7555420d147222888bf refs/tags/REL8_4_3
> Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
> Date: Fri Feb 19 00:40:06 2010 +0000

> This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'.

> Cherrypick from master 2010-02-19 00:40:05 UTC Peter Eisentraut <peter_e(at)gmx(dot)net> 'Translation updates for 9.0alpha4':
> src/bin/pg_dump/po/it.po

> A src/bin/pg_dump/po/it.po

After some more experimentation I believe I've found the answer: what we
should do is hack the CVS history so that the branch revisions sprout
from the mainline revision that they should logically have sprouted
from, not the chronologically-most-recent revision. When I modify it.po
as shown in the attached patch, I get a conversion that has no funny
business at all: it.po is deleted where it should be, and added where it
should be, and there's *no* manufactured commit anywhere.

Now, when you look at the patch, it's probably going to scare the
daylights out of you. But it's really not that bad. What we're doing
is renumbering the 1.7.6.1 revision to 1.5.6.1 (because it now sprouts
from 1.5 not 1.7 on the mainline) and replacing its delta content with
an appropriate delta from 1.5 not 1.7. The delta content is easily
generated via "cvs diff -n" between the relevant versions --- AFAICT
all we have to do to the diff output is double any @-signs. We can also
easily verify that we did it right, by checking out the branch revision
from CVS afterwards and seeing that it has the right content.

Once I understood what needed to be done, it took me about two minutes
to make these changes manually. I'm inclined to think it's not worth
developing a tool for it --- we could probably manually fix the couple
dozen files that need to be fixed in less time than that would take.

Comments?

regards, tom lane