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