git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Stefan Bucur <stefan.bucur@gmail.com>
Cc: git@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Wrong file diff for merge conflict
Date: Sun, 5 Jul 2009 17:33:36 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0907051726020.3210@localhost.localdomain> (raw)
In-Reply-To: <8cdebd3f0907051523q73494603ka8a50b19b1238a@mail.gmail.com>



On Mon, 6 Jul 2009, Stefan Bucur wrote:
> 
> Thank you for your suggestions for a better and more efficient merging
> experience, as I'm sure they will help me from now on. However, I
> think I did not make myself clear: I was not arguing the fact that the
> merge result was suboptimal, but the fact that _the generated conflict
> file is semantically wrong_.

Oh. 

No, you're confused about what a conflict file is.

> Basically, if one would take the common (successfully merged) parts
> and keep the "left" parts in the conflict sections, one would obtain
> the first branch version of the file (with minor modifications).

No. This is not how conflicts work.

If you blindly do that, you'll always get the wrong answer. Why? Because 
you're ignoring the parts of the file that didn't conflict. Those will be 
_outside_ the conflict markers in all cases.

> Similarly, if one would opt to keep only the "right" parts in the
> conflict section, one would obtain the version found in the second
> branch before merge.

Same problem. What you expect from a conflicting file is simply not true.

The fact is, a traditional rcs three-way merge (which is pretty much what 
you get with git, ignoring the fact that we have other tools in addition 
to it, and ignoring things like criss-cross merges etc) just doesn't work 
the way you seem to think it should work. You simply don't get the 
original of one side by picking one side of the conflict markers. It will 
have merged the stuff that it thought merged cleanly, and not have any 
conflict markers at all for those parts.

Of course, "what it thought merged cleanly" may not be what you want it to 
be. Sometimes you get a clean merge for things that you'd have wanted to 
conflict. And sometimes you get conflicts for stuff that you'd think is 
just silly and shouldn't have. 

There are no perfect file merge algorithms that I know of. Lots of people 
hate the diff3/merge behavior - it's by no means perfect. But so far, I've 
never seen anybody successfully advocate anything better either.

		Linus

  reply	other threads:[~2009-07-06  0:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-04  7:53 Wrong file diff for merge conflict Stefan Bucur
2009-07-05 18:43 ` Linus Torvalds
2009-07-05 19:22   ` Jakub Narebski
2009-07-05 19:23   ` Junio C Hamano
2009-07-05 22:23   ` Stefan Bucur
2009-07-06  0:33     ` Linus Torvalds [this message]
2009-07-06 14:44       ` Stefan Bucur

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=alpine.LFD.2.01.0907051726020.3210@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=hpa@zytor.com \
    --cc=stefan.bucur@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).