Re: [PATCH 2/4] name-rev: allow converting the exact object name at the tip of a ref

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 8, 2013, 15:12 UTC
Message-ID: <7v38rp2ihg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0kSqaMrD_YuT8OxLo8yLEc0APd2Ca7FapKstqqmcYbC7A@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>   Finds symbolic names suitable for human digestion for revisions
>   given in any format parsable by git rev-parse.
>
> It is meant to name _revisions_ (aka. commits):

That is a mistaken documentation, written based on a half-baked implementation that conflated "the current code only can handle commits" with "we need to only handle commit and nothing, ever".

We had to fix a similar misguided/short-sighted implementation in the "git fetch" codepath when adding "git pull/merge $tag" (the code peeled a tag object too early when writing FETCH_HEAD out, losing information if what we were given was a tag or a commit).

I do not want to see us making the mistake worse unnecessarily. When we see a commit object that is pointed by tag v1.8.3, it is the right thing to do to return v1.8.3^0 as its string representation so that "git rev-parse v1.8.3^0" give us the same thing back. name-rev that is fed a tag object v1.8.3 should give v1.8.3 (not v1.8.3^0) back, otherwise feeding its output to "git rev-parse" will not give us the same thing we fed as the input to name-rev.