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 definition excludes symrefs.
* 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?
How about:
ref
A binding of a name to an object or other ref (in which case it
is a symref). Refs are stored in the repository.
The ref namespace is hierarchical. Different subhierarchies
are used for different purposes (e.g. the refs/heads/ hierarchy
is used to represent local branches).
>
> If we also want to explain the implementation details of refs, then
> additionally at the end of the first paragraph, add:
>
> ... at an object name, by storing its 40-byte hex
> representation. They are implemented as either a file in
> $GIT_DIR/refs/ directory (called "loose refs") or an entry
> in $GIT_DIR/packed-refs file (called "packed refs"); when a
> loose ref exists, a packed ref of the same name is ignored.
It would be good to document this somewhere, but I'm not sure the
glossary is the right place for it. Maybe gitrepository-layout(5)?
-Richard
--
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
