Re: cherry picking and merge

["Philip Oakley" <philipoakley@iee.org>]

From: "Mike Stump" <mikestump@comcast.net>
Sent: Friday, August 01, 2014 11:24 PM
> On Aug 1, 2014, at 12:01 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>> It can work in Subversion because Subversion stores information about
>> what was merged in (and this includes cherry-picks, or whatever it is
>> named in svn) in svn:mergeinfo property. Git does not track what was
>> merged in, instead it represent the history as the graph of 
>> revisions,
>> and tracks merges (by storing that it came from two or more commits)
>> and not merged-in information.
>
> So, as a dumb user that just wants it to work, I am unsympathetic to 
> the `but software is hard’ excuse.  I am aware that some bugs are 
> harder to fix than others.  svn took a long time to fix this bug, but 
> they did.  I can wait, the only question is, will it be a week, a 
> month, a year, or a decade.
>
>> When merging Git uses only what is being merged and its common
>> ancestor (3-point merge). It is simple, and simple works!!!
>
> I gave a solution for git using branches and it works just fine.  It 
> retains the simple 3-point merge as well.

At the moment there is no formal way for Git to record within the commit 
metadata the inclusion of the cherry-picked diff (the 'merge' of the 
fix).

Thinking out of the box, the issue is that the commit parents list does 
not have a formal mechanism to allow the recording that the 'merged' 
change was the patch change from a specific commit fom somewhere else 
(which may be missing from the local repo).

Perhaps it needs a style of merging-rebase where a second (last) parent 
is added but it isn't the straight <sha1>, but says 'patch-<sha1>', such 
that readers with the capability could check if that <sha1> history is 
present locally, and if so if it's correct, so that you can now 'track' 
your fixes between releases, and (hopefully) older Gits don't barf on 
that extra 'fake' parent. Somehow I suspect that older Git's would 
barf.. (not enough time to create and test such a fake commit)

>
>> Unfortunately, it does not see cherry-picked commits - it is 
>> invisible
>> to merge as being on the chain from one of merged commits to the
>> common ancestor.
>
> Im the solution that I sketched in my previous email, that information 
> is then exposed so that the right merge happens.
>
>> The rebase command handles
>
> I can’t use rebase as it is unfriendly to coworkers.
>
>> cherry-picked commits by detecting that the
>> change was already applied. I think that git-imerge does the same 
>> (but
>> I have not used it myself).
>>
>> Have you tried git-imerge?
>
> No, not yet.  I’m not as interested in using it, as I would like git 
> itself to just work.

--
Philip