Re: Question regarding git fetch

Avery Pennarun [off-list ref] writes:

On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda[off-list ref] wrote:

quoted

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.

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