On 2009.08.27 15:36:53 +0000, Avery Pennarun wrote: > On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda<tom.lambda@xxxxxxxxx> wrote: > > What was a little bit surprising to me is that running "git fetch central > > master" does not update refs/remotes/central/master but simply updates > > FETCH_HEAD. > > I've often wanted this myself, especially when doing things like "git > pull origin master". However, I know the current behaviour is also > useful sometimes, and changing it would introduce an unexpected side > effect. Git currently promises that your refs/remotes/* branches will > never be updated unless you explicitly request it, even if you're > fetching, merging, and pulling other stuff. This means you can write > scripts to do complicated things without triggering unexpected > user-visible side effects. > > So basically, I agree that it would often be much more user-friendly > to do what you're asking. But it would be less scripting-friendly. I > don't think anyone has thought of an answer that better balances the > two. It would also be pretty hard to implement that. Given the default fetch refspec, it would "simply" be a matter of mapping the given ref to the refspec, so e.g. "foo" becomes "refs/heads/foo:refs/remotes/origin/foo". But even just using "git remote add -t master foo git://..." breaks that, as the fetch refspec in the config will no longer be a glob, and thus no such mapping is possible. Björn -- 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