Show 78 quoted lines
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>
>> "git merge" produces a (IMHO) wrong result, when a commit from the
>> branch that is to be merged in was cherry-picked into the current branch
>> and later reverted on the original branch. Basically ignoring the
>> revert.
>>
>
> There are a few issues around 3-way merge.
>
> One thing is, what happened in between the common ancestor and the final
> results on histories before you initiate the merges does not matter. When
> doing a 3-way merge, you look only at three endpoints: your final state,
> their final state and the common ancestor between the two.
>
> Your history looks like this:
>
> 123a456
> 3-----------?
> / /
> / /
> 0-----1-----2
> 123456 123456
>
> During the development between 0..2, your undecision might have caused the
> contents of the file fluctuate back and forth many number of times, but in
> the end result, you (the one who went 0..1..2) decided that for your
> development, you do not have to change the contents of that path. The
> path might have been a xyzzy.h file, and you once added an extern decl of
> a function because you thought a function in xyzzy.c might be needed by
> another file frotz.c, but it turned out that the function can stay private
> and you removed that extern decl from xyzzy.h and ended up in the same
> state.
>
> But the other person who built the history 0..3 decided that having the
> change is better than not having it. Perhaps his code does use the
> function from some other place and needs an extern.
>
> You are merging the two histories, which means by definition you trust
> your decision and the other guys decision with equal weight. And here is
> another thing.
>
> When you compare the path in question at 0 and 2, you see they are
> identical. And you are interpreting that "I say they MUST STAY THE SAME,
> while they say they want to change it some way, that is a conflict".
>
> But in 3-way merge context, you do not interpret the fact that something
> is identical between 0..2 as "they MUST STAY THE SAME". Instead, you read
> it as "My history does not care what happens to that path -- if the other
> guy wants to change it, I'll happily take it."
>
> Note. I am not claiming that the above interpretation will always
> match what you would expect. I am just explaining how the underlying
> concept of 3-way merge works in general. If you think about it in a
> realistic context, such as the "extern in xyzzy.h you did not need to
> add but the other guy needed to have", you'll realize that more often
> than not, "I do not care and let the other guy decide" interpretation
> results in a more useful result.
>
> That essentially boils down to three rules:
>
> (0) If both of you did not change anything, the final result won't have
> any change (obvious);
>
> (1) If you decided you do not have a need to change a path, but the other
> one saw a need, you take the change;
>
> (2) If you and the other one both wanted to change a path but in a
> different way, you need to merge at the contents level.
>
> And you are seeing rule (1) in action.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Ittay Dror <ittay.dror@gmail.com>