Jeff King <peff@xxxxxxxxxx> writes: > Given 1/2/3, you would look for tags in: > > refs/remotes/1/tags/2/3 > refs/remotes/1/2/tags/3 > > and then similarly heads in: > > refs/remotes/1/heads/2/3 > refs/remotes/1/2/heads/3 > And then complain of ambiguity if they both match (which will almost > _never_ happen, unless you have a totally insane repo setup. So this is > really just about having well-defined rules just in case, and probably > won't affect most people in practice. In most cases, it will just DWYM). > > The "HEAD" thing remains simple. You check for: > > refs/remotes/1/2/3/HEAD > > since HEAD is going to be at the top-level anyway. Gaah, why is this even a good thing? Yes, you demonstrated that it is _possible_ to define disambiguation rules, but do we currently allow (or horrors encourage) hierarchical remote nicknames, and do people rely on being able to do so? What workflows benefit from such a confusing layout? I am not fundamentally opposed to it, but just trying to tell between "we do so because we can" and "because we need to for such and such reasons". -- 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