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

On Wednesday 08 June 2011, Nguyen Thai Ngoc Duy wrote:

(Sorry for the late answer. Unfortunately, I don't have much Git time these days...)

Browsing that thread, it seems my proposal was largely OK. AFAICS there are no major technical problems with moving to the following ref mapping:

  Remote repo    ->   Local repo
  --------------------------------------------------
  refs/heads/*        refs/remotes/$remote/heads/*
  refs/tags/*         refs/remotes/$remote/tags/*
  refs/replace/*      refs/remotes/$remote/replace/*
  refs/notes/*        refs/remotes/$remote/notes/*

There was a fair amount of discussion around whether we really _want_ to put all refs (especially tags) in separate per-remote namespaces, and it seems (both from that thread, and from later threads, like this one) that we _do_ want per-remote namespaces for all refs.

That said, there are a couple of outstanding questions/challenges before this can be implemented:

1. How to deal with tag auto-following

The tag auto-follow behavior currently depends on the implicit "refs/tags/*:refs/tags/*" refspec, and the "refs/tags/" prefix is presently hardcoded both at the local and remote end. If we want to support auto- follow behavior in the new ref mappings (e.g. specified with a "~" prefix: "~+refs/tags/*:refs/remotes/$remote/tags/*"), we must change code both on the local and remote side. In order to get optimal behavior we will probably also need to make some protocol changes.

On the other hand, it is not clear how useful tag auto-following really is. Quoting Peff from the earlier thread ( http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160726 ): "Now you could argue that auto-follow is not worth the effort. It is somewhat confusing, and I can't think of a time when it ever actually reduced the set of objects I was fetching (as opposed to just fetching all tags). But maybe others have use cases where it matters."

Or, quoting Junio further down in the thread ( http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166694 ): "Also if you give tags a totally separate namespace, I don't see much reason to still give it the "auto-follow" semantics. It is far simpler to explain if you just fetch all of them and be done with it, no?"

So far nobody have stood up to defend the current auto-following behavior as a necessary feature.

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:

- "foo" should still be usable for "refs/heads/foo", "refs/tags/foo", etc.

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

- For tag name "foo": "refs/tags/foo" (if exists) is unambiguous.

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

- Extra care must be taken across different "types" of refs, depending on 
the context. I.e. in some situations we might want to prefer 
"refs/remotes/origin/heads/foo" to "refs/remotes/otherremote/tags/foo", or 
the other way around (or flag the ambiguity and abort).

3. Migration path

We need both styles of ref mappings ("traditional", with the implicit and auto-following tag refspec, and "new-style", where all refspecs are explicit) to work side-by-side in the same repo (i.e. having one remote use traditional refspecs, while another uses new-style). At first, we will probably still default to the traditional refspecs when creating a new remote, but over time we should migrate to new-style refspecs, before finally deprecating the traditional refspecs. I'm not sure if traditional vs. new-style can be reliably autodetected from the refspecs themselves, or if we need an explicit per-remote config variable to discern between the two.

I think all of the above problems are solvable.

...Johan