Re: Improving auto conflict resolving while merge

[Jeff King <peff@peff.net>]

On Mon, Sep 07, 2015 at 08:15:46PM +0300, KES wrote:

> 1. git clone https://github.com/KES777/Plack
> [...]
> At this point I have same changes on master and branch.
> master head is d095870
> branch head is a3db36a
> fork point is 0a5ff84

I tried re-merging d095870 and a3db36a. I think what is happening is
that even though you have many similar hunks near each, there are still
some differences in the area, and they are close enough that the merge
isn't sure what is right. We err on the side of conservatism with
conflicts, because it's hard to say what is dependent and what is not.

For example, if you have the content:

  foo();
  bar();
  baz();

and one side makes it:

  foo();
  x = 1;
  bar();
  baz();

and the other side does:

  foo();
  bar();
  y = 2;
  baz();

you _could_ argue that those changes are independent (and write a merge
algorithm that silently merges them). They're touching two different
lines, and doing two different things. But it's close enough that
there's a good chance the two need to be reconciled, and a human should
at least take a look.

I think what further confuses things in your case is that the content
added by the two sides contains a lot of similar lines (because of the
cherry-pick), and the default "merge" conflict-markers try to shrink the
size of the conflicts.

Try running:

  git config merge.conflictstyle diff3

and re-doing the merge. It will give you a much better sense of how git
is breaking down the hunks (because it does not try to shrink the
conflicts, and because it shows the base content for each conflict).

-Peff