Thomas Rast <trast@xxxxxxxxxxxxxxx> 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. -- 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