Re: [PATCH] Remove restriction on notes ref base
- From
Jeff King <peff@peff.net>
- Date
- Nov 5, 2010, 14:55 UTC
- Message-ID
- <20101105145510.GA19087@sigill.intra.peff.net>
- In-Reply-To
- <201011050229.15941.johan@herland.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).
Show 10 quoted lines
> > 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.
Show 13 quoted lines
> 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