Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre <nico@fluxnic.net>]

On Mon, 7 Feb 2011, Jeff King wrote:

> I guess the problem is that I'm not clear on exactly what the new lookup
> / ambiguity rules are proposed to be. Clearly something will need to go
> in the dwim_ref level. And I think it's obvious that if "refs/tags/foo"
> and "refs/remotes/*/tags/foo" point to the same sha1, they will not be
> considered ambiguous.

Agreed.

> Will the same apply to refs/heads/foo versus refs/remotes/*/foo?

I think it should.  If both branches are pointing to the same commit 
then the short form "foo" should be unambigous and the operation proceed 
(be that 'git push' or 'git log' that shouldn't matter).

> Will it
> also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the
> final case, that does matter to "git push" (should the destination be in
> the head or tag namespace?).

In such a case I'd say that head refs have precedence over tag refs, and 
when that occurs  then warn the user.  And I wouldn't make a special 
case for 'git push' here.  Whether it is push or log, the head ref would 
take precedence, and the user warned about existence of a tag with the 
same name.  Of course using "tag/foo" should be unambigous again.

> So the actual names of the ref can matter,
> and should probably be taken into account when deciding what is
> ambiguous.

What happens today when you have refs/heads/foo and refs/tags/foo?


Nicolas