Richard Hansen <> writes:

> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to