On Tue, Apr 13, 2021 at 05:26:02PM -0700, Chris Torek wrote: > On Tue, Apr 13, 2021 at 5:18 PM Sam Bostock <sam.bostock@xxxxxxxxxxx> wrote: > > Long story short, it seems to me that `git fetch` should update > > "refs/remotes/origin/HEAD" when the upstream HEAD changes, but it > > doesn't. > > It's never been the *intent* to have `git fetch` update > the corresponding remote-tracking `HEAD` ref. To make > that happen, you must run `git remote`: > > git remote set-head origin -a > > for instance. > > I have, however, often thought that this is the wrong > *default* way for things to work, and that at least by default, > `git fetch origin` should update `origin/HEAD` if the > fetch result indicates that it should. See also Junio's > reply. I think a configuration knob (similar to `fetch.prune`) > would be reasonable here. Users could then be encouraged > to set `fetch.prune` to `true`, and `fetch.update-remote-HEAD` > (or whatever) to `true` as well. I think so, too. The previous discussion Junio referred to it is here: https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@xxxxxxxxx/ If you do read it, note that the parts of the conversation about unborn heads are out of date. We do pick this up via clone these days, courtesy of the commits in 69571dfe21 (Merge branch 'jt/clone-unborn-head', 2021-02-17). -Peff
