Re: cherry picking and merge

From: Jakub Narębski <jnareb@gmail.com>
Date: Aug 1, 2014, 16:27 UTC
Message-ID: <53DBBFE8.8060607@gmail.com>
In-Reply-To: <20140801024329.GA28914@vauxhall.crustytoothpaste.net>

W dniu 2014-08-01 04:43, brian m. carlson pisze:

> On Thu, Jul 31, 2014 at 05:58:17PM -0700, Mike Stump wrote:

Show 21 quoted lines

>> Cherry picking doesn’t work as well as it should.  I was testing on
>> git version 1.7.9.5.
>>
>> Put in a line in a file, call it:
>>
>> first version
>>
>> then cherry pick this into your branch. Then update on master and transform that into:
>>
>> second version
>>
>> then, merge that branch back to master.  Death in the form of conflicts.
>>
>> In gcc land, I do this sort of thing all the time, and I need a
>> merging subsystem to actually keep track of things.  I can manage this
>> will diff and patch and it works flawlessly.  The point of using
>> something better than diff and patch is for it to be better than diff
>> and patch.
>>
>> I’d like for merge to merge in the work that has yet to be merged.
>> Not that, plus blindly try and apply or reapply cherry picked items.

Note that you should try to avoid cherry-picking, as they do not leave trace in the graph of revisions.

For example if you are creating a bugfix, instead of putting it directly on maint, and then cherry-picking to master, it is better to create a separate feature branch for this fix (based at an early version), and then merge said branch into maint, then into master. It is described in blog post by Junio Hamano (which I cannot find now).

Show 12 quoted lines

> You're not the first person to be surprised by the way merge works.
>  From the git-merge manpage:
>
>    [This behavior] occurs because only the heads and the merge base are
>    considered when performing a merge, not the individual commits.
>
> (That was added after 1.7.9.5.)
>
> If you want the behavior of applying multiple patches in a row, you want
> to use git rebase, not git merge.  Since rebase re-applies the patches
> of each of your commits on top of another branch, the identical change
> won't cause conflicts.

There is also git-imerge, third party tool that is intended to help merging changes (and make it possible to do it in incremental way).

HTH

-- 
Jakub Narębski