Re: [1.8.0] make two-argument fetch update remote branches

On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast [off-list ref] wrote:

Proposal:

Running "git fetch origin master" only updates FETCH_HEAD, not
origin/master, which turns out to be quite confusing for newcomers
especially after running 'git pull origin master'.

Since the remote branches in some sense reflect the "last known state"
of the remote, it would make sense to also update them to whatever a
two-argument fetch got.

Risks:

Scripts might rely on the current behaviour.  The most likely case I
can think of would be to go along the lines of

 git fetch origin master
 git rev-list origin/master...FETCH_HEAD | do_something

to avoid relying on reflogs to get the same result.  Seems a bit
arcane to me though.  Such usage would see the updated state, i.e.,
process an empty range.

Migration plan:

Add a fetch.updateRemoteNamespace (or so) configuration variable that
defaults to false.  When enabled, it turns on the auto-updating
behaviour.

In 1.8.0, flip the default.

--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

+1 I really wanted to write this one my self;)

I would disagree with the migration plan though.
IMHO there is no need to introduce the variable. If it will start
update both FETCH_HEAD and the remote-tracking branches since 1.8 it
will not break any code, because it is added functionality...
In this case FETCH_HEAD will reflect the latest fetch and it doesn't
even need to be removed later on.

just my 2 cents...

Thanks,
Eugene