Re: Question regarding git fetch

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Aug 27, 2009, 16:46 UTC
Message-ID: <20090827164657.GA17090@atjola.homenet>
In-Reply-To: <32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com>

On 2009.08.27 15:36:53 +0000, Avery Pennarun wrote:

Show 18 quoted lines

> On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda<tom.lambda@gmail.com> 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