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

[Johan Herland <johan@herland.net>]

On Wednesday 08 June 2011, Nguyen Thai Ngoc Duy wrote:
> 2011/6/8 Sverre Rabbelier <srabbelier@gmail.com>:
> > Heya,
> > 
> > [+Peff, Duy, who seemed interested in this]
> > 
> > On Wed, Jun 8, 2011 at 14:52, Ingo Molnar <mingo@elte.hu> wrote:
> >> So it would be nice to have more separation for remotes - right now
> >> they do not sit still in their sandboxes! :-)
> > 
> > Sounds like the "tags should go in their own namespaces in git 1.8.0"
> > [0] discussion? :)
> > 
> > [0]
> > http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=16
> > 5837
> 
> A lengthy thread. Does anybody remember the outcome? Was Johan's
> proposal OK and only waiting to be implemented, or is there still
> unanswered questions?

(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

-- 
Johan Herland, <johan@herland.net>
www.herland.net