On Mon, Feb 14, 2011 at 10:22:55PM -0800, Junio C Hamano 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. 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 -- 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