On Mon, Nov 08, 2010 at 09:14:27AM -0500, Martin von Zweigbergk wrote: > On Mon, Nov 8, 2010 at 8:48 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > On Mon, 8 Nov 2010, Martin von Zweigbergk wrote: > >> Sorry, maybe I misunderstood what the confusion was about. What I was > >> referring to was the confusion caused by 'git fetch origin master' not > >> updating 'refs/remotes/origin/master'. > > > > Should it really do it? ÂWhat if it does not exist? ÂWhat if <remote> > > is specified via URL? > > I would probably not expect it to be updated (even if the URL matches a > configured remove). If the reference does not yet exist, I think I would > expect it to be created. Yeah, the patch I posted a while back (and referenced below) does not convert URLs into remote names (nor do I think it should). But if you give it the name of a configured remote, and it is fetching a ref from the remote that is mentioned on the LHS of a configured fetch refspec, it will update the matching RHS of that refspec opportunistically. So it should be pretty unsurprising to the user (see the thread below for some discussion of when it could be surprising). > Also see http://thread.gmane.org/gmane.comp.version-control.git/127163/. > Junio, Jeff and Avery can argue much better for and against this than I > can. I read it at some point, but I don't quite remember now if they did > discuss the historical reasons for the current behavior in that thread. I took a look at cleaning up the patch from that thread. It causes 4 of the test scripts to fail. Most disturbing is this one: $ grep explicit.fetch t/t5510-fetch.sh test_expect_success 'explicit fetch should not update tracking' ' which checks for the direct opposite of the behavior we are discussing. The test was added by Junio in late 2007. However, I can't seem to find any discussion on the mailing list about it. Junio, do you remember anything about this? -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