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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html