On Tue, 23 Aug 2005, Len Brown wrote:
> I'm having trouble using git for merging kernel trees.
> git seems to manufacture conflicts in files that
> I never touched, and on some files it completely
> throws up its arms, see "Not handling case" below.


You've found a case where git-merge-base finds what appears to be two 
equally good merge candidates, but they really aren't.

The merge candidates are 30e332f3307e9f7718490a706e5ce99f0d3a7b26 and 

To see this graphically, do:

        echo 30e332f3307e9f7718490a706e5ce99f0d3a7b26 > 
        echo 3edea4833a1efcd43e1dff082bc8001fdfe74b34 > 

        echo 81065e2f415af6c028eac13f481fb9e60a0b487b > 
        echo 702c7e7626deeabb057b6f529167b65ec2eefbdb > .git/refs/tags/lenb-head

        gitk --all

and notice how the not-selected one is:

        Author: Antonino A. Daplas <[EMAIL PROTECTED]>  2005-08-15 06:29:11
        Committer: Linus Torvalds <[EMAIL PROTECTED]>  2005-08-15 09:59:39
        Tags: not-selected

while the selected on is:

        Author: Luming Yu <[EMAIL PROTECTED]>  2005-08-11 21:31:00
        Committer: Len Brown <[EMAIL PROTECTED]>  2005-08-15 12:46:58
        Tags: selected

and the reason we chose that one is that it's three hours later than the 
other one, and we don't know any better.

> Not clear how I got into this state -- probably
> something to do with adding commits on branches
> and them git-pull-branch'ing them into the master;
> combined with updating the master from-linus.

No, it's git.

Well, it's git, together with your propensity to merge old work, which 
causes this kind of confusion where there are two "equally good" points to 
choose from as the merge base, and git chose the wrong one because it 
_looked_ newer and there was a recent merge to an old version of my tree. 

Cross-merges cause this, but I'm sure there's a good algorithm for 
selecting _which_ of the two interesting commits to pick.

Give me a moment to think about this.

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

Reply via email to