On Mon, Jul 08, 2013 at 06:38:32PM +0530, Ramkumar Ramachandra wrote: > Junio C Hamano wrote: > > With this on top of the other patches in this series, you would get: > > > > $ git describe --contains $(git rev-parse v1.8.3 v1.8.3^0) > > v1.8.3 > > v1.8.3 > > > > while you can still differentiate tags and the commits they point at > > with: > > > > $ git name-rev --refs=tags/\* --name-only $(git rev-parse v1.8.3 > > v1.8.3^0) > > v1.8.3 > > v1.8.3^0 > > > > The difference in these two behaviours is achieved by adding > > --peel-to-commit > > option to "name-rev" and using it when "describe" internally calls it. > > Essentially a revert of [2/4] for describe-purposes, achieved by > adding an ugly command-line option to name-rev.
I don't think it is a revert. The two patches complement each other. 2/4 is basically "if we have a non-commit object which is pointed at directly by a tip, make sure we name it by that tip". But you can only get such an object by "name-rev --stdin", since name-rev peels its command-line arguments. 4/4 is "stop peeling command line objects, so we can find their exact tips". IOW, it lets the command line do the same thing that --stdin was able to do in 2/4. > Before we argue any further, let me ask: who uses name-rev (and > depends strongly on its output)?! Our very own testsuite does not > exercise it. There are exactly two users of describe/name-rev: > > 1. prompt, obviously. > 2. DAG-tests, for simplification. Yeah, I'm not clear on who we are breaking with the change in default peeling behavior, nor why the "describe --contains" wrapper wants to keep it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
