Linus Torvalds <torvalds@xxxxxxxx> writes: > On Sat, 30 Sep 2006, Junio C Hamano wrote: >> >> However, I think the traditional "find the closest ancestor" >> behaviour and ref-log behaviour are mutually incompatible, while >> they both return information to help address similar issues to >> the end user when viewed at a very high level. >> >> Especially, "find the closest ancestor" behaviour means when you >> get "tag-gXXXX" as an answer, the tag proper does _not_ contain >> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of >> v1.4.2). > > Correct. > > But that just means that we should take the _next_ one in the time-ordered > list, no? I do not think so. Extending the example (sorry for doing the same topic on two separate threads) I just gave Jeff on "fix based on v0.99", after finding that the fix is based on v0.99, finding another commit that immediately followed the v0.99 commit on my master branch does not help finding out that I very recently merged the fix in at all. I think we cannot get away without honestly doing the first descendant, which is unfortunately a lot more expensive. - 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