Re: [PATCH 2/4] glossary: define committish (a.k.a. commit-ish)

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 20, 2013, 10:55 UTC
Message-ID: <CALkWK0nqOSmFaYhbW3anmBvgy2=DZs7qU0kz7=eEO5R99uLAqQ@mail.gmail.com>
In-Reply-To: <51C2409F.1070801@bbn.com>

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.