Re: cherry picking and merge

From: Philip Oakley <philipoakley@iee.org>
Date: Aug 1, 2014, 18:57 UTC
Message-ID: <4EA0D79811C348C6893039D315E6E190@PhilipOakley>
In-Reply-To: <5AF18A76-DD3B-4B9A-BF70-EFE4BB852C3D@comcast.net>

From: "Mike Stump" <mikestump@comcast.net>

Show 32 quoted lines

> 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