Re: git: uh-oh - Mailing list pgsql-hackers

On 20/08/10 18:43, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 19:41, Max Bowsher <maxb@f2s.com> wrote:
>> On 20/08/10 18:30, Magnus Hagander wrote:
>>> On Fri, Aug 20, 2010 at 19:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Max Bowsher <maxb@f2s.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.

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.

Max.