Richard Hansen <rhan...@bbn.com> 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
> * 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html