Richard Hansen wrote:
> * Aren't HEAD, FETCH_HEAD, ORIG_HEAD also refs?
HEAD is a symbolic ref [*1*], FETCH_HEAD is not a ref [*2*], and
ORIG_HEAD is a ref.
> 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.
What is "binding of a name"? It's a file that contains exactly one
line: a 40-character SHA-1 hex. End of story. Like I explained in
[*1*], I see no advantage in grouping symbolic refs with refs.
> The ref namespace is hierarchical. Different subhierarchies
> are used for different purposes (e.g. the refs/heads/ hierarchy
> is used to represent local branches).
Good.
[Footnotes]
*1*: HEAD is the one and only symbolic ref, unless you create more by
hand using `git symbolic-ref`. Unfortunately, no other symbolic ref
can ever be on the same footing as HEAD: the sources hard-code "HEAD"
in a large number of places, and reworking it to truly support
symbolic refs is probably not worth the pain at all. If you want to
convince yourself that this is true, run `git symbolic-ref H HEAD` and
then try to resolve H@{u}: HEAD@{u} resolves fine, doesn't it?
*2*: It's not an "ordinary file" like COMMIT_EDITMSG either, in that
rev-parse can operate on it. It is not a ref because it contains
references to several objects; cat it and see for yourself.
--
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
