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

Thomas Rast [off-list ref] writes:

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.

The overall goal is a good one, I think, but it is not a migration plan
without a period where we issue a loud, in-your-face, warning to force
users to choose, is it?  I suspect you just didn't write it because it is
so obvious, but I am just making sure it is written down somewhere, so
that whoever ends up implementing this will not forget.

Thanks.