From: Linus Torvalds Date: Mon, 05 Sep 2005 16:01:32 GMT Subject: Re: bogus merges Message-ID: In-Reply-To: <59a6e58305090507387d412b3d@mail.gmail.com> 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 > 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