Re: git: uh-oh

On Sat, Aug 21, 2010 at 08:15, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Max Bowsher wrote:
>> 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.
>
> I think this would be nontrivial.

<snip>


> Moreover, this is a pretty specialized request that would be useless to
> people who are not so disciplined about their repository as you seem to be.

Yeah, I think we're unusually disciplined with our repository - that's
one reason the change won't be that drastic wrt how things are done
:-)


> It seems like you already have a way to find these events in the git
> repository after conversion, so I think it would be more practical to
> use git-filter-branch to remove the unwanted commits *after* the conversion.

Not sure that we do have an automated way, but I agree that this is
probably going to be easier to do with git-filter-branch.

If we need to do it at all. Tom's latest lookover indicates that he
thinks it may be good the way it is, and we need some more detailed
checks. I know Robert has said he wants to dedicate some time to doing
such checks this week, and I'll see if I can find some time for that
as well. If anybody else would like to help us dig through mainly the
backbranches - with focus on branchpoints and taggings - to look for
any kind of "weird stuff" (meaning anything that's not a straight
commit), then please do so and let us know your results!


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