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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html