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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html