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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]