Re: Inexplicable merge conflict produced when when lines next to each other are changed

2015-04-28 Thread Jeff King
On Tue, Apr 28, 2015 at 07:34:30AM +, Anuradha Dissanayake wrote:

 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.

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


Inexplicable merge conflict produced when when lines next to each other are changed

2015-04-28 Thread Anuradha Dissanayake
I posted this question to StackOverflow a while ago but no one answered 
it so I thought I'd try here.

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? 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.

It's an issue in our company because there are certain files where 
multiple developers change lines in close proximity and this causes many 
unnecessary conflicts when they pull.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html