On Thu, Aug 27, 2009 at 02:20:46PM -0700, Junio C Hamano wrote: > I think it is reasonable, in 1.7.0, to change "git fetch" with command > line refspacs that lack colon (i.e. saying "fetch this ref" without saying > "and store it here") so that it updates remote tracking refs if and only > if an appropriate remote.$remote.fetch is configured to do so. E.g. when > I fetch from Eric for git-svn updates with > > $ git pull git-svn master > > because I do have > > [remote "git-svn"] > url = git://yhbt.net/git-svn > fetch = +refs/heads/*:refs/remotes/git-svn/* Does the colon really matter? That is, should $ git fetch git-svn master store a tracking ref, but $ git fetch git-svn master:foo not? In both cases, git has learned during the course of an operation what the new value of the tracking ref could be, so why not store it? The obstacle I see is that somebody may be using configured refspecs as something other than a tracking ref. That is, they care about _when_ those refs on the RHS of the refspec are updated, and are not treating them just as a cache of what the remote side has. > On the other hand, if my refspecs for "git svn" _were_ like this: > > [remote "git-svn"] > url = git://yhbt.net/git-svn > fetch = +refs/heads/master:refs/remotes/git-svn/master > > then I would _not_ want this: > > $ git fetch git-svn dev > > to create a new tracking branch refs/remotes/git-svn/dev. Of course not. It's not in your configured refspec, so you have requested no such tracking ref. I think we would have to limit ourselves to how the tracking refs are defined in the refspecs. Otherwise how would we know to put the tracking ref in refs/remotes/git-svn and not some other place? So I think it is a simple matter of applying the configured refspecs with information we happen to have gotten during the course of a somewhat-related operation. -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