Re: Improving auto conflict resolving while merge

From: Jeff King <peff@peff.net>
Date: Sep 8, 2015, 07:06 UTC
Message-ID: <20150908070645.GH26331@sigill.intra.peff.net>
In-Reply-To: <856611441646146@web13j.yandex.ru>

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

Show 6 quoted lines

> 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