Re: git-rev-parse --symbolic-abbrev-name [was Re: git-branch --print-current]

From: demerphq <demerphq@gmail.com>
Date: Jan 4, 2009, 12:40 UTC
Message-ID: <9b18b3110901040440i70ce50d0v8996b8fef33a58cf@mail.gmail.com>
In-Reply-To: <quack.20090104T0434.lthfxjz1c8x_-_@roar.cs.berkeley.edu>

2009/1/4 Karl Chen <quarl@cs.berkeley.edu>:

Show 13 quoted lines

>>>>>> On 2009-01-03 21:17 PST, Junio C Hamano writes:
>
>    Junio> That is a good point about user education, and is a
>    Junio> demonstration why a new option to cover a very
>    Junio> narrow-special case to symbolic-ref will not help the
>    Junio> situation.  People will add their own embellishments
>    Junio> around the name of the branch anyway, and the most
>    Junio> generic symbolic-ref output is just as useful as a
>    Junio> special case option to show without refs/heads/.
>
> That's arguable :) you really think "branchfoo" instead of
> "refs/heads/branchfoo" is a narrow special case?  Seems like a
> common case for everyone except plumbing tools.

I agree. All the scripting I've done involves using the non qualified form.

Show 10 quoted lines

> Here's a more general idea you might like better:
>
>    git symbolic-ref --abbrev BLAH
> or even
>    git rev-parse --symbolic-abbrev-name BLAH
>
> This would be like git-rev-parse --symbolic-full-name, but strips
> the "refs/x/" iff the result is unambiguous.  Since it's much more
> work for a script to check whether the stripped version is
> ambiguous, this functionality is appropriate as a builtin option.

I vote for this, I could and would use it many scripts. Also please dont make it die if BLAH is not a symbolic ref if this option is used. Just return nothing.

cheers, Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"