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

From: Emeric Fermas <emeric.fermas@gmail.com>
Date: Feb 15, 2011, 06:32 UTC
Message-ID: <AANLkTimaYFbDsAooSuP+BBMA8mJYwupPCgJUj8UGqrQx@mail.gmail.com>
In-Reply-To: <7vsjvpq0jk.fsf@alter.siamese.dyndns.org>

Thanks a lot for this very clear explanation. All my questions have found an answer.

Cheers, Em.

On Tue, Feb 15, 2011 at 7:22 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 28 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.
>
> 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.
>
> This won't change very much if we decide to reorganize the remote tracking
> hierarchies in 1.8.0.  The former won't change at all, and the latter will
> start pointing at refs/remotes/<the same remote name>/heads hierarchy
> instead.
>
> I vaguely recall tg abused the symref mechanism to point .git/HEAD at
> funny locations; it may still be doing so, and if that is the case we
> should extend the above list to cover that usage.
>