Re: cherry picking and merge

[Jonathan Nieder <jrnieder@gmail.com>]

Jonathan Nieder wrote:

> Do you mean that "git merge" should be aware of what changes you have
> already cherry-picked?
>
> It isn't, and that's deliberate

That said, when today's "git merge" fails to resolve conflicts, it's
easily possible that we could do better at resolving the merge by
walking through both sides and understanding what happened.

The detailed history lets you

   i) Present conflicts in an easier to resolve way.

      "Patch #1 which tries to do X conflicted with patch #2 which
      tries to do Y; please reconcile them" can be less painful to
      deal with than "Something in this pile conflicted with something
      in that pile".

  ii) Break a seeming conflict into pieces that can be automatically
      resolved more easily.

      X vs X'+Y may conflict where X' is a cherry-pick of X, if X and
      Y touch the same code.  Meanwhile if we're lucky then X vs X'
      will not conflict because they make the same change, and Y can
      apply on top.

 iii) Handle cherry-picked changes in a *different* way.  For example,
      if patch X was applied on one side and applied and then reverted
      on the other side, this could show up as a conflict.  After all,
      the two sides don't agree on whether patch X is a good change or
      not.

These features have corresponding downsides:

   i') (Speaking from experience of using git-imerge) Too many tiny
       conflicts can sometimes be more painful to resolve than all the
       conflicts at once.  When X, Y, Z, and W had various conflicts,
       how to reconcile X and Y alone or Z and W alone are academic
       questions that don't actually need to be answered to produce
       the merge result.

  ii') This kind of clean, broken-down merge can produce a "clean"
       but wrong result.

       For example, if the following sequence of events occured:

         1. Build fancy new feature X on "master".

	 2. Cherry-pick X to the bugfixes-only branch "maint".
	    Whoops.
	 3. Correct the mistake: revert X on "maint".  Now "maint"
	    is bugfixes-only again!

	 4. Merge "maint" to "master".

       Then a naive, 3-way merge will notice there is no change
       on "maint" since it was last merged to master and the
       merge will bring in no change (good).

       And on the other hand a one-patch-at-a-time merge would
       try to apply X (with no effect, since it's already applied)
       and then try to apply the revert of X.  The net effect would
       be to revert X from "master" (bad)!

 iii') See (ii').

git-imerge from https://github.com/mhagger/git-imerge can help with
(i) and (ii) but not (iii).

Hoping that clarifies,
Jonathan