On Wed, Mar 25, 2015 at 03:21:35PM +0300, Konstantin Khomoutov wrote: > On Mon, 23 Mar 2015 17:47:47 -0700 (PDT) [...] > IIUC, you seem to imply that since line4 has been changed only on > the one side, there should be no conflict. For a simple merge > between two commits which share common history, Git uses the > tree-way merge -- that is, it considers not only the states the > content being merged has at both sides of the merge but their > nearest common ancestor commit as well. I have recreated your > situation (using only local branches, but that should not matter), > then extracted all the three versions of the file -- "theirs", > "ours" and "common ancestor" -- and run GNU `diff3 -m` on them, and > got the same result: line4 is considered changed as well. > > So, I'm not sure where to go from there. I seem to understand your > reasoning, but while it certainly had a valid grain in it I'm not > sure it's universally correct. Let me explain: suppose these are > not mere abstract "lines" but rather the code of some imperative > program. To start with, when you merge, typically it's assumed that > both sides maintain their content in a "correct" state (yeah, in a > philosophical sense): say, the program as the "theirs" side have it > is correct and the program as the "ours" side has it is correct as > well -- even though they differ. Now suppose that we apply your > reasoning to the detection of conflicts when merging and do not mark > "ours-only" change at line4 as conflicting. The problem there is > that the code on the lines before line4 in "theirs" program might > rely on line4 being in the exact state it is! Your approach to > merging would "silently sneak" a change breaking the "theirs" state > of the program steering your focus away from that fact because the > conflict would be elsewhere in the file.
`diff` needs a bit of surrounding "stuff" (context) to match up the unchanged bits of the files. I think that's what's causing this behaviour, on one side line 4 is changed, on the other it isn't, this pushes the unchanged context past line 4 and hence it turns up as changed. At least this is my understanding of how the algorithm works. > Hence I'm inclined to deem this case as "working as intended" even > though the result appears somewhat counter-intuitive for this > particular case. I'm inclined to do the same. /M : https://en.wikipedia.org/wiki/Hunt%E2%80%93McIlroy_algorithm -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Finagle's Second Law: Always keep a record of data -- it indicates you've been working. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Description: PGP signature