On Mon, 23 Mar 2015 17:47:47 -0700 (PDT)
<hibig...@gmail.com> wrote:

[...]
> Remote "sample.txt" has been chanaged bellow,
> ---sample.txt@remote---
> line1:
> line2:
> line3:SERVER
> line4:
> line5:
> ---(EOF)---
> 
> Local "sample.txt" has been changed like bellow,
> ---sample.txt@remote---
> line1:
> line2:
> line3:CLIENT
> line4:CLIENT
> line5:
> ---(EOF)---
> 
> At first, I pushed "smaple.txt@remote" to remote repository
> Next, I fetched origin and merged FETCH_HEAD.
> 
> Then, conflict occured like this...
> ---conflict---
> line1:
> line2:
> <<<<<<< HEAD
> line3:CLIENT
> line4:CLIENT
> =======
> line3:SERVER
> line4:
> >>>>>>> FETCH_HEAD
> line5:
> ---(EOF)---
> 
> I think line4 is not conflicted, but merge result shows conflict at
> line3 and line4.
> 
> I want to get the merge result like following.
> ---conflict---
> line1:
> line2:
> <<<<<<< HEAD
> line3:CLIENT
> =======
> line3:SERVER
> >>>>>>> FETCH_HEAD
> line4:CLIENT
> line5:
> ---(EOF)---
> 
> Is it configuration problem?
> 
> [Remote bare repository]git version 1.7.1 on CentoOS6.6
> [Local repository]git version 1.9.4.msysgit.2 on Windows7

You're merging

line1:
line2:
line3:SERVER
line4:
line5:

into

line1:
line2:
line3:CLIENT
line4:CLIENT
line5:

Merging means reconciling changes both "sides" of the merge have to
produce the contents which, logically, includes the changes made by all
the sides in a way such that the result "takes into account" what both
sides contribute to the result.

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.

Hence I'm inclined to deem this case as "working as intended" even
though the result appears somewhat counter-intuitive for this particular
case.

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

Reply via email to