Re: cherry picking and merge

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

From: "Mike Stump" <mikestump@comcast.net>
> On Aug 1, 2014, at 9:27 AM, Jakub Narębski <jnareb@gmail.com> wrote:
>>
>> Note that you should try to avoid cherry-picking, as they do not
>> leave trace in the graph of revisions.
>
> Fine, then I want a new command to merge in a change into my branch 
> from another branch and I want merge to account for the motion and not 
> duplicate it when I merge that branch back into master.  Funny thing 
> is, cherry and merge seem to be documented mostly to do exactly what I 
> want.
>
>> 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
>
> You’re assuming that I’m the author of master, I’m not, I’m merely a 
> contributor.  This tail doesn’t wag that dog.  What that means is that 
> I cannot change the world to work around a simple bug in git.
>
>> 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).
>
> Then remove git merge and replace it with git-imerge.  :-)  Anyway, I 
> read that, and I can see some beauty of that that might be nice in 
> complex merges.  The problem is, I want git merge to work.
>
>
> I was curious if svn handles this better the same or worse, and it did 
> it just fine.  I know that a while ago, svn could not handle this, it 
> would do what git does currently.  Apparently they figured out it was 
> a bug and fixed it.  Have you guys figured out it is a bug yet?  The 
> first step in solving a problem, is admitting you have a problem.
--
But that goes both ways, and is a philosophical issue about what is to 
be expected in various cases. For some central control use styles, the 
ideas behind _distributed_ version control are anathema and (Git) just 
grinds away at the policies that are expected.

That said, Git doesn't claim to be perfect (and can't because of the 
'relativity' that comes with being distributed - truth has to give way 
to a web of trust). Also the artefacts that Git validates are at a 
different level of abstraction i.e. the whole project as a commit, 
rather than just a few/one file at a time.

In your example (when generalised) the problem is deciding when, in the 
change sequence, the cherry pick is to be backed out, especially if 
there are conflicts in the change sequence that would need fixing 
anyway, and in a long change sequence that would be a lot of conflict 
fix-ups, hence the current choice of getting the merge conflicts all 
resolved in the one go.

The alternate case, mentioned/implied by Brian, is to use a rebase 
(probably after duplicating the branch so as to retain the original if 
required) so as to see each patch/changeset being applied, and doing 
any/many conflit resolutions as they appear, before finally doing any 
merge of the new line of development back into the mainline (which again 
presumes your earlier resolutions don't cause more conflicts on that 
merge). But do note that I've hidden the problem of deciding where the 
rebase start point should be, relative to the merge point, because 
that's actually where the original problem is hidden (which bits merge 
with what!)

git-imerge is a visual tool to show which bits merge cleanly with what 
between two change sequences.

Selecting a compatible workflow is a problem of usage, rather than a 
problem in Git. If Git has a problem, it's that it has too many ways of 
doing things, leaving most of us with too much rope entangled round our 
neck.
--
Philip