Re: unexpected git-merge result

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Feb 20, 2010 at 03:45:09AM +0000, Dale Rowley wrote:
> 
> You're exactly right. I overlooked the cherry-pick, which clears things up a
> bit. But the basic problem remains:
> 
> A----D---E---H
>  \          /
>   B--D'----G
> 
> G only removed a few of the lines that were brought over in the cherry-pick
> (D'), so it was surprising when they re-appeared in H. Intuitively, one would at
> least expect a conflict in H since D'+G is asserting that these lines should not
> exist, whereas D (on the other branch) is asserting that they should. I can see
> how it would be difficult to make git-merge account for this though, so maybe
> this is just a subtle gotcha when merging branches? Is there an easy way to
> avoid this gotcha?

git merge does 3-way merge, which means that it does not look at whole
history but only on the current state and the merge base. So, if you
look at changes between A and G then those lines were not touched, and
A-E adds those lines, thus the end result is that these lines are added.


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]