Re: Inexplicable merge conflict produced when when lines next to each other are changed
On Tue, Apr 28, 2015 at 07:34:30AM +0000, Anuradha Dissanayake wrote:
Show 33 quoted lines
> Let's say I have a file with this content in master:
>
> _____
> Line 1
> Line 2
> Line 3
> Line 4
> _____
>
> Now say I create and checkout a new branch called Test. In this branch I
> change the file to this:
>
> _____
> Line 1
> Line 2
> Line 3 Modified
> Line 4
> _____
>
> and I commit this and switch back to master. In master I change the file
> to:
>
> _____
> Line 1
> Line 2
> Line 3
> Line 4 Modified
> _____
>
> and I commit. Now if I merge branch Test into master, I get a conflict.
>
> Why can't git auto resolve this, as those are two entirely independent
> lines?
The content-level merge in git looks for overlapping diff hunks. It does have a "level" setting which will try with varying degrees of effort to shrink the conflict section, but I do not think there is a setting that will resolve this cleanly. Short of teaching a new level to the libxdiff merge code, I think the best you can do is to specify your own content-level merge driver for these files, and feed the data to another program which does the merge differently (whether it is simply more aggressive at finding conflicts, or it might even know something about the semantics of the file). See the "three-way merge" section in "git help attributes".
Show 5 quoted lines
> If I tell git to edit conflicts using BeyondCompare as the
> difftool, BeyondCompare autoresolves this without even telling the user,
> since this isn't a real conflict (other merge tools we use at our
> company do so also). Is there a way to get git to autoresolve these?
> I've tried the recursive and resolve merge strategies but neither do it.
I don't think a change of merge strategy will help; they all end up doing the content-level merge with the same libxdiff code.
-Peff
PS I'm answering your "how to" questions directly without considering
whether what you are asking for is a good idea. But you may want
to think about whether there is a case that matches the above pattern
that you would _not_ want to auto-resolve (i.e., even though there is
not strictly a textual conflict, there is a good chance there is a
semantic conflict because the lines are so close together).