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 > 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. -- 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
