Re: git: uh-oh

On Fri, Aug 20, 2010 at 19:56, Max Bowsher <maxb(at)f2s(dot)com> wrote:
> On 20/08/10 18:43, Magnus Hagander wrote:
>> On Fri, Aug 20, 2010 at 19:41, Max Bowsher <maxb(at)f2s(dot)com> wrote:
>>> On 20/08/10 18:30, Magnus Hagander wrote:
>>>> On Fri, Aug 20, 2010 at 19:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>> Max Bowsher <maxb(at)f2s(dot)com> writes:
>>>>>> The history that cvs2svn is aiming to represent here is this:
>>>>>
>>>>>> 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
>>>>>> did *not* exist.
>>>>>
>>>>>> 2) Later, it was added to trunk.
>>>>>
>>>>>> 3) Then, someone retroactively added the branch tag to the file, marking
>>>>>> it as included in the REL8_4_STABLE branch. [This corresponds to the git
>>>>>> changeset that Robert is questioning]
>>>>>
>>>>> Uh, no.  We have never "retroactively added" anything to any branch.
>>>>> I don't know enough about the innards of CVS to know what its internal
>>>>> representation of this sort of thing is, but all that actually happened
>>>>> here was a "cvs add" and a "cvs commit" in REL8_4_STABLE long after the
>>>>> branch occurred.  We would like the git history to look like that too.
>>>>
>>>> Yeah.
>>>>
>>>> In fact, is the only thing that's wrong here the commit message?
>>>> Because it's probably trivial to just patch that away.. Hmm, but i
>>>> guess we'd like to hav ethe actual commit message and not just another
>>>> fixed one..
>>>
>>> There is no "actual commit message" - the entire changeset is
>>> synthesized by cvs2git to represent the addition of a branch tag to the
>>> file - i.e. the logical equivalent of a "cvs tag -b", which has no
>>> commit message.
>>
>> There is a commit message on the trunk when the file was added there.
>> Is there any chance of being able to lift that message off trunk and
>> just copy it into the branch, instead of saying "this is a cherry-pick
>> of this commit over here"?
>
> It wouldn't be accurate to do so, because the synthetic commit is not
> copying the entire change, only registering the addition of (in this
> case) one file which happens to be part of the changeset. Please note
> that there is a changeset on the branch immediately following the
> synthetic one under discussion which contains the 'real' commit message
> used when committing to the branch.

Hmm. Good point.

I wonder if we should try to locate these places and fix them with git
filter-branch or rebase -i after the fact, with history rewriting.

There seem to be 57 of them.

Searching for those, I also found a bunch with the comment "Sprouted
from <branch>". What do those mean?

> 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.

Well, the one Robert pointed to is a very recent commit. Not sure if
it uses the client version or the server version - the version on
cvs.postgresql.org is:

[mha(at)cvs ~]$ cvs --version

Concurrent Versions System (CVS) 1.11.17-FreeBSD (client/server)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/