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

From: Jeff King <peff@peff.net>
Date: Jun 14, 2011, 17:12 UTC
Message-ID: <20110614171204.GC26764@sigill.intra.peff.net>
In-Reply-To: <201106141156.56320.johan@herland.net>

On Tue, Jun 14, 2011 at 11:56:56AM +0200, Johan Herland wrote:

Show 11 quoted lines

> 2. Interpreting/DWIMing refs
> 
> Changing the ref mappings require a revised set of rules for interpreting 
> shorthand ref names (expanding them into full ref names), and handling 
> ambiguities when they arise:
> [...]
> 
> - "origin/foo" must continue to work, even if "refs/remotes/origin/foo" has 
> now become "refs/remotes/origin/heads/foo". In other words, "foo/bar" where 
> "foo" is a valid remote, must try to resolve "bar" against the refspecs 
> specified for the "foo" remote.

What happens if I ask for foo/bar/baz? Should it try to resolve:

  1. refs/remotes/foo/heads/bar/baz

or

  2. refs/remotes/foo/bar/heads/baz

or both (and if both, in which order)?

I don't know offhand if "git remote" and "git clone" allow slashes in remote names, but I don't think we forbid it if somebody configures it themselves (and of course, remote names aside, they are free to write whatever refspecs they like in the config file).

Show 13 quoted lines

> - If "refs/tags/foo" does not exist, tag name "foo" is unambiguous if it 
> exists in one or more "refs/remotes/*/tags/foo" and they all point to the 
> same SHA1.
> 
> - If "refs/tags/foo" does not exist, and more than one 
> "refs/remotes/*/tags/foo" exist, and they do NOT all point to the same SHA1, 
> then there is an ambiguity.
> 
> - The user may resolve the ambiguity by creating "refs/tags/foo" pointing to 
> the chosen SHA1 ("refs/tags/foo" takes precedence over 
> "refs/remotes/*/tags/foo").
> 
> - The same rules apply to heads, notes, etc.

I'm not sure we need all of these rules for anything but tags. We already keep remote heads in a separate namespace, and we don't automagically look them up. And that's OK, because the way tags and heads work is fundamentally different. I can peek at your remote heads, but if I checkout or merge, I better make a local branch that matches your remote one. Whereas with tags, I don't think that is the case. They're really a read-only thing, and you want them to stay in the remotes namespace.

I think notes should behave more like heads. You can use them as-is if you just want to look, but you need to use the full remote name. And if you want to do more (like keeping your own notes and merging somebody's remote notes in), then you'll make your own local notes branch, and use "git notes merge" to keep it up to date.

-Peff