From: Jeff King <peff@peff•net>
To: Anuradha Dissanayake <falconne@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Inexplicable merge conflict produced when when lines next to each other are changed
Date: Tue, 28 Apr 2015 22:35:10 -0400 [thread overview]
Message-ID: <20150429023509.GB438@peff.net> (raw)
In-Reply-To: <loom.20150428T093059-405@post.gmane.org>
On Tue, Apr 28, 2015 at 07:34:30AM +0000, 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).
prev parent reply other threads:[~2015-04-29 2:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 7:34 Inexplicable merge conflict produced when when lines next to each other are changed Anuradha Dissanayake
2015-04-29 2:35 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150429023509.GB438@peff.net \
--to=peff@peff$(echo .)net \
--cc=falconne@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox