On Thu, Dec 17, 2015 at 12:28:48PM -0800, Junio C Hamano wrote: > By the way, a totally unrelated niggle I have with 2073949 is this. > > $ git describe --contains 2073949 > v2.3.1~3^2~4 > > while as you said, this dates back to at least v2.2.0-rc0 > > $ git tag --contains 2073949 > v2.2.0 > v2.2.0-rc0 > ... > v2.7.0-rc1 > > That "describe --contains" output comes from "name-rev --tags", and > I need to force it to use v2.2.0-rc0 as the source of naming, i.e. > > $ git name-rev --refs=refs/tags/v2.2.0-rc0 2073949 > 2073949 tags/v2.2.0-rc0~13^2~9 > > to get what I would expect to be more useful. > > I know "name-rev --contains" wants to describe a commit based on an > anchor point that is topologically closest, and even though I do not > offhand think of any, I am sure there are valid use cases that want > to see the current behaviour. But from time to time, I wish it did > its naming taking the topological age of the anchor points into > account. If a commit is contained in v2.2.0-rc0 and onward, even > though v2.0.0-rc0~13^2~9 describes a longer path from v2.0.0-rc0 > than v2.3.1~3^2~4 is from v2.3.1, I often want to see the name based > on the "oldest" tag (if such a thing exists, and for older commits > in this project, it always is the case, I think). Yes, I agree (and judging by the number of "git describe is confusing" threads over the years, I think it is not just us). I rarely use "git describe --contains" myself. What I typically use (and how I arrived at v2.2.0 in this instance) is: git tag --contains "$@" | grep ^v | grep -v -- -rc | sort -V | head -1 But there are some git-specific assumptions in there. -Peff -- 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