Re: Q: how can i find the upstream merge point of a commit?

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 15, 2011, 23:53 UTC
Message-ID: <7vips6ircc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110615230033.GB19803@sigill.intra.peff.net>

Jeff King <peff@github.com> writes:

Show 9 quoted lines

> 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

Show 10 quoted lines

> 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".