Re: [PATCH 4/4] describe/name-rev: tell name-rev to peel the incoming object to commit first

From: Jeff King <peff@peff.net>
Date: Jul 9, 2013, 05:12 UTC
Message-ID: <20130709051252.GG27903@sigill.intra.peff.net>
In-Reply-To: <CALkWK0nMmQO=cML-s9rgku+_4fZnYwtGC+daYPOBPn6-RFZj=g@mail.gmail.com>

On Mon, Jul 08, 2013 at 06:38:32PM +0530, Ramkumar Ramachandra wrote:

Show 19 quoted lines

> 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.

Show 6 quoted lines

> 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