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

[Jeff King <peff@github.com>]

On Wed, Jun 15, 2011 at 04:53:55PM -0700, Junio C Hamano wrote:

> Jeff King <peff@github.com> 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?

I do think it's slightly insane, but if we are going to have "foo/bar"
map into "refs/remotes/foo/heads/bar", then we have to start giving some
significance to the slash; a straight append won't work anymore. It may
be enough to say "the first slash always ends the part between "remotes"
and "heads" (i.e., remotes cannot have slashes).

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

My reasoning is that we don't disallow remote names with slashes, nor do
we disallow people putting arbitrarily nested refs into refs/remotes. So
in the name of compatibility, we should assume people are doing it and
not break them.

If we want to declare this illegal, I'm not too opposed. The only use
case I could think of is somebody who works with two different sets of
remotes, like "upstream" people and internal people. E.g., if I'm at
company "foo" working on linux internally, I might have a few remotes:

  origin: linus
  foo/alice: coworker alice's tree
  foo/bob: coworker bob's tree

And then I could ask questions that involve globbing on the refs like
"which commits are in my company but not published upstream?"
Something like:

  git log \
    `git for-each-ref --format='%(objectname)' refs/remotes/foo/*` \
    --not linus/master

I've never actually seen anything like this, though. That was just the
only useful example I could come up with.

-Peff