Re: git: uh-oh

On 25/08/10 01:15, Robert Haas wrote:
> On Fri, Aug 20, 2010 at 1:56 PM, Max Bowsher <maxb(at)f2s(dot)com> wrote:
>> My guess at this point is that there may be a (very old?) version of cvs
>> which, when adding a file to a branch, actually misrecorded the file as
>> having existed on the branch from the moment it was first added to trunk
>> - this would explain this anomaly.
>
> I think this is what is happening, except I'm unable to account for it
> by the age of the CVS version we're runnning. The machine the CVS
> repo is running on is running 1.11.17-FreeBSD (client/server). I
> don't know how long it's been that way, but there are examples of this
> in the relatively recent past - like July 2nd of this year. I am 100%
> positive that what I did was 'cvs add' one new file, 'cvs delete' one
> old file, modify a few other things, and commit the whole deal. But
> in the git conversion there are two commits, one of which adds a copy
> of the file as it exists in HEAD and the other of which contains the
> balance of the changes. Every recent manufactured commit is of this
> same form: it immediately precedes the commit of which (in my view) it
> should be considered a part.
>
> Looking back a bit further in history, there is some stranger stuff.
>
> commit ec0274633871c43da670fa90d0ac4fd7090639f2
> Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
> Date: Mon Jun 6 16:30:43 2005 +0000
>
> This commit was manufactured by cvs2svn to create branch 'REL8_0_STABLE'.
>
> Cherrypick from master 2005-06-06 16:30:42 UTC Bruce Momjian <bruce(at)momjian(dot)
> doc/src/FAQ/FAQ_hungarian.html
>
> And then, much later, the following completely empty commit:
>
> commit 446b749c2eaeff3c0611d33bc12b3df28e2cf8fa
> Author: Bruce Momjian <bruce(at)momjian(dot)us>
> Date: Tue Oct 4 14:17:44 2005 +0000
>
> Add FAQ_hungarian.html to 8.0.X branch.
>
> What really happened is:
>
> http://archives.postgresql.org/pgsql-committers/2005-10/msg00044.php
>
> So that's pretty much the same thing, except the time lag between the
> two commits that should be married is much larger.

Yup, exact same problem, the file was added to the branch, and CVS
erroneously recorded that it *had existed on the branch* from the moment
it was created on trunk.

> The odder cases are the ones involving deletion. There are a couple
> of branches/tags that, or so I'm guessing, are only present for a
> subset of the files in the repository: ecpg_big_bison, creation,
> Release-1-6-0, MANUAL_1_0, REL2_0B, and SUPPORT. I'm wondering if we
> shouldn't just nuke those, or at least nuke them from the copy of the
> repository upon which we are running the conversion.

Well, I'd caution against being too revisionist with your history, but
if you're convinced you want to drop certain tags/branches, you can
configure cvs2git to ignore them (see the symbol strategy rules part of
the options file).

Max.