Uwe Kleine-K?nig <zeisberg@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Shawn O. Pearce wrote: > > $ git rev-list v1.5.0-rc0..next | wc -l > > 687 > > $ git rev-list v1.4.4.4..next | wc -l > > 1051 > > > > So what about doing Junio's suggestion of going by topology and > > coming up with the possible set of tags (v1.5.0-rc0 and v1.4.4.4 > > right now), and if more than one is found compute the number of > > commits between each tag and the requested revision, and take the > > tag that has a smallest number of commits? > > One scenario where this will fail is when a bugfix is commited on top of > v1.4.4.4 and then is merged into v1.5.0-rc0+gabcdef. Actually it still works, and does what you want. The scenario you are describing is exactly the one that caused this bug to appear, and is the one my suggestion is trying to offer a partly sane solution to. Try it. Checkout v1.4.4.4, make a trivial commit, merge it to master, then merge that to next. You'll still come up with the fact that master (or next) have less commits different from v1.5.0-rc0 than they have from your hypothetical v1.4.4.5. In this case the the v1.5.0-rc0 tag should still be taken. Its easy to explain this difference in terms of what the user sees via `git log` and `git rev-list`. We're taking the tag which has the fewest commits different. This will hold even if `next` suddenly gets another 800 new commits (changing the above counts to 1847 and 1851 respectively). Where it might fail is if v1.4.4.5 suddenly gets another 1000 commits as part of its bug fix release and those all get merged into next. Now v1.4.4.5 is closer than v1.5.0-rc0. But you know what, that does still make a lot of sense. If you look at the git log (or git shortlog) between v1.4.4.5 and next there's less output than if you look at it between v1.5.0-rc0 and next. -- Shawn. - 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