Emeric Fermas [off-list ref] 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.
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 [off-list ref] wrote:
Emeric Fermas [off-list ref] writes:
quoted
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.
On Mon, Feb 14, 2011 at 10:22:55PM -0800, Junio C Hamano wrote:
Emeric Fermas [off-list ref] writes:
quoted
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.
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