Re: Question regarding git fetch

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 27, 2009, 21:20 UTC
Message-ID: <7viqg9q7gx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com>

Avery Pennarun <apenwarr@gmail.com> writes:

Show 13 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.

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/*

defined, it is Ok to update refs/remotes/git-svn/master (but not others).

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.

It used to be that the only way to check the progress of other people were to do this:

	$ git fetch git-svn master
	$ git log git-svn/master..FETCH_HEAD

But these days, even if we changed the "git fetch" semantics, we can still rely on reflogs to do the equivalent with:

	$ git fetch git-svn
	$ git log git-svn/master@{1}..git-svn/master

In other words, I think the "feature" that an explicit "fetch but do not store this time" request to prevent "git fetch" from updating the tracking branches outlived its usefulness.