Re: What's the definition of a valid Git symbolic reference?

From: Jeff King <peff@peff.net>
Date: Feb 15, 2011, 07:09 UTC
Message-ID: <20110215070939.GB28634@sigill.intra.peff.net>
In-Reply-To: <7vsjvpq0jk.fsf@alter.siamese.dyndns.org>

On Mon, Feb 14, 2011 at 10:22:55PM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> Emeric Fermas <emeric.fermas@gmail.com> writes:
> 
> > Once again, by reading at the code I can understand how those commands
> > currently work. What I'm trying to achieve is to understand what
> > should be their recommended usage.
> 
> There are only two valid kinds of symrefs right now:
> 
>  - .git/HEAD, pointing at somewhere under refs/heads/ hierarchy;
> 
>  - .git/refs/remotes/<some remote name>/HEAD, pointing at somewhere under
>    refs/remotes/<the same remote name>/ hierarchy.

Nit: the notes merge code uses NOTES_MERGE_REF as a symref to a notes
ref. See the create_symref call in builtin/notes.c.

I don't think that changes your point much, though.

Show 5 quoted lines

> The code may be prepared to resolve recursive symrefs, symrefs other than
> the above two kinds, symrefs that point at elsewhere, but all of them are
> outside of the design scope of what the mechanism was intended to support.
> What the code do to them (without crashing) is not the design, but simply
> an undefined behaviour.

I was always under the impression that you could generally use symbolic refs to point wherever you wanted inside the refs hierarchy as a replacement for symlinks (I don't know how the latter would deal with ref packing, though). But I think that was just my assumption rather than anything that was ever communicated officially.

-Peff