Re: Merge seems to get confused by (reverted) cherry-picks

[Ittay Dror <ittay.dror@gmail.com>]

Note: codeville tried to implement a merge algorithm that considers the 
history to decide what the user wants to do: 
http://revctrl.org/PreciseCodevilleMerge. Maybe worth while exploring?

Ittay

Junio C Hamano wrote:
> 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 <ittayd@tikalk.com>
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>


-- 
--
Ittay Dror <ittay.dror@gmail.com>