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@xxxxxxxxx> wrote: > Emeric Fermas <emeric.fermas@xxxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html