On Mon, 5 Sep 2005, Wayne Scott wrote:
>
> A recent commit in linux-2.6 looks like this:
It hopefully shouldn't happen any more with the improved and fixed
git-merge-base.
> Author: Russell King <[EMAIL PROTECTED]>
> Date: Wed Aug 31 10:12:14 2005 +0100
I suspect rmk is using cogito-0.13, and that it still has the older
git-merge-base that can get confused by the date-ordering problem. And
when git-merge-base gives the wrong result (not either of the commit
objects it was given as an argument), then "git resolve" will do the wrong
thing.
I just checked, and the _current_ git-merge-base definitely gives the
right result:
linux$ git-merge-base -a \
6b39374a27eb4be7e9d82145ae270ba02ea90dc8 \
194d0710e1a7fe92dcf860ddd31fded8c3103b7a
results in
194d0710e1a7fe92dcf860ddd31fded8c3103b7a
ie it correctly notices that the second commit is the parent of the first
one.
> Really 'git commit' should detect problems like this automatically and
> prevent them from getting in the tree.
Well, that would depend on having the fixed git-merge-base in the first
place, which in turn would mean that such a commit wouldn't happen at all,
so it's kind of circular. It's not worth fixing anywhere else, since once
you fix it in git-merge-base, it just becomes a non-issue.
Hopefully we'll have a new cogito release soon, and this particular bug
will be a thing of the past.
Linus
-
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
