Re: [PATCH] Remove restriction on notes ref base

[Jeff King <peff@peff.net>]

On Fri, Nov 05, 2010 at 02:29:15AM +0100, Johan Herland wrote:

> Actually, I don't have anything against auto-follow per se, and we could 
> easily enough extend the refspec to specify auto-follow behaviour: There is 

Yup, agreed. That would be sufficient to capture the current behavior
(and IMHO makes it much more transparent to the user).

> > This codifies that refs for remote $foo are in refs/remotes/$foo, which
> > is something we have avoided so far. For example, when finding the
> > "upstream" branch, we have the name of the remote and the merge branch,
> > look up the fetch refspecs in the config, and then figure out where that
> > branch would be fetched to. Which of course turns out as you say (as
> > remotes/$remote_name/$branch) in the default config, but we don't
> > restrict people to that.
> 
> We can do the same for "foo/bar" as well, although things become slightly 
> more fiddly:

Yeah, I don't think the problem is unsurmountable. But I do think it is
worth doing the more complex behavior, as it keeps things "right" with
respect to arbitrary config.

> When "foo" exists as a remote, look up its fetch refspec(s), and determine 
> possible mappings for name "bar". I.e. given the following (non-default) 
> refspecs for remote "foo":
> 
>   +refs/heads/*:refs/remotes/spam/heads/*
>   +refs/tags/*:refs/remotes/eggs/tags/*
>   +refs/notes/*:refs/remotes/bacon/notes/*
> 
> we know that the intersection between the left side of these refspec and the 
> ref disambiguation rules consists of "refs/tags/bar" and "refs/heads/bar" 
> (in that order). We can then map these to the right side of the refspec to 
> get "refs/remotes/eggs/tags/bar" and "refs/remotes/spam/heads/bar" (in that 
> order). We would then use the first match from these alternatives.

Yeah, that makes sense. If the remote side is storing tags somewhere
besides "refs/tags" you wouldn't find them, but that is probably a good
thing.

-Peff