Re: [PATCH 2/4] glossary: define committish (a.k.a. commit-ish)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 20, 2013, 03:25 UTC
Message-ID: <7vli65wjj2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <51C2409F.1070801@bbn.com>

Richard Hansen <rhansen@bbn.com> writes:

Show 19 quoted lines

> On 2013-06-19 18:36, Junio C Hamano wrote:
>> Ahh.  If you had quoted [...] a few exchanges ago I would have
>> immediately understood what you were trying to say.
>
> Sorry about that, my bad.
>
>> In today's world (after packed-refs was introduced), probably
>> 
>> 	A name that begins with refs/ (e.g. refs/heads/master) that
>> 	can point at an object name.
>> 
>>         The namespace of refs is hierarchical and different
>>         subhierarchy is used for different purposes (e.g. the
>>         refs/heads/ hierarchy is used to represent local branches).
>> 
>> is an appropriate rewrite of the above.
>
> Some thoughts about the above definition:
>   * Aren't HEAD, FETCH_HEAD, ORIG_HEAD also refs?

That is a shade of gray. "refs" are names we use as the starting point to construct extended SHA-1 expressions to refer to objects, and in that sense they are. It would be complete to mention these as special cases.

>   * That definition excludes symrefs.

True. "... that can directly point at an object, or point at another ref (the latter is called a symbolic ref)."

>   * It may be worthwhile to mention that refs are part of the
>     repository.
>   * Is a ref a name?  Or is it the binding of a name to an object/ref?

I am not particularly interested in pedantry, but I think in the way we used the word "ref", it is a name. "refs/heads/master" is the full name of the ref and it can be abbreviated to 'master' when not ambiguous. And there is a mechanism to read what the the ref has to learn the name of the object (*not* object/ref) it refers to (the name of that mechanism being "ref resolution").

To a layperson, a ref is one of the ways you can name an object with.