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

On 20/08/10 19:07, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 19:56, Max Bowsher <maxb@f2s.com> wrote:
>> 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.
>
> 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.

It sounds cumbersome.

Michael Haggerty might be better placed than me to assess whether
eliding them within cvs2git is practically achievable.

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

It appears as part of the description of what a synthetic branch
creation commit did, existing only to put into context the operations
that follow - i.e. the creation of the REL7_4_STABLE branch involved
sprouting from trunk, then deleting 4 files which were not included on
the branch.

The revision described in the "Sprout ..." line isn't particularly
interesting, since it's always the same as the parent of the commit -
it's just listed for symmetry with "Cherrypick ..." lines which may follow.

The presence/absence of a "Sprout ..." line indicates whether the
particular commit is the initial creation of a branch, versus the
grafting in of additional files to the branch. (The latter occurs when a
file is tagged as if it was part of the branch from the creation of the
branch, but only initially came into being *after* there were already
commits 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.
>
> 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@cvs ~]$ cvs --version
>
> Concurrent Versions System (CVS) 1.11.17-FreeBSD (client/server)

Unsure, I'm afraid. Though I might try hunting through CVS's CVS.

Max.