On Tue, Nov 17, 2020 at 8:39 PM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Jeff King wrote: > > On Tue, Nov 17, 2020 at 07:45:21PM -0600, Felipe Contreras wrote: > >> Jeff King wrote: > > >>> Yes, I have run into that, and it's definitely annoying. The > >>> refs/remotes/<remote>/HEAD symref is created by clone, but is not > >>> updated by "fetch". That's intentional, because it's supposed to > >>> represent a local choice (that is merely seeded by the remote side). But > >>> it seems like adding it if it's missing might be reasonable. > >> > >> The equivalent of this choice is in "git remote add -m": > >> > >> With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` > >> is set up to point at remote's `<master>` branch. See also the > >> set-head command. > > > > Wow, I'm not sure how that option escaped my notice for all these years. > > Of course it would be much more useful if it pulled the value from the > > remote HEAD (but again, unless we use "-f" we are not contacting the > > remote at all). > > When would I want this implicit "set-head -a" and *not* want "-f"? This is what I often do: git remote add origin $url git fetch origin That should work (update origin/HEAD), and it currently doesn't. > > E.g., remote.origin.updateHEAD that can be set to one of: > > > > - never; do not touch it > > > > - create-if-missing; as discussed here > > > > - always; update it on every fetch > > > > And then it is just a question of what the default is. Currently it is > > "never". I suspect most people would be happy with "always", but it does > > break some existing flows. But perhaps "create-if-missing" is a good > > medium. > > Thanks for bringing this up --- this is something I had been > interested in as well but hadn't gotten around to contacting the list > about it. > > The default value for a config setting like this has two purposes: > > - it makes the config setting for affected people who have not > discovered it > > - it provides a sensible, predictable standard behavior > > Those two goals are often in tension, as they were for example when > setting the default for push.default. > > If I consider them separately: > > - to make as smooth a transition as possible for people who were > relying on "git remote set-head", a good behavior would be to > *fail the fetch* when the remote HEAD changes. That would force > the user to make a choice between "never" and "always". We don't need to fail the fetch, we can print a warning so the user can decide what to do next, including ignoring the warning. Moreover, since projects rarely change the HEAD, we might want to print the warning always, until the user sets the configuration. > - one way to relax that without hurting that goal too much would be to > fail the fetch when the remote HEAD changes from something other > than "master" or "main". That way, the common case (moving from a > default to a project-appropriate setting) would work without > friction, and in other cases the user could make a choice between > "never" and "always". This thread started in an attempt to move away from hard-coded values. This doesn't help in my opinion. > - all that said, the default that I prefer is simply "always". Like > Felipe hinted, this is a simple, intuitive behavior that most people > would expect. > > As a transition plan, I can imagine going from one of those first two > to the third after some appropriate period of time has passed. I think the default should be "missing", after a warning period. And perhaps change it to "always" in the next major version, but that basically gets rid of the manual "origin/HEAD" that seems to have been there since forever (at least 2007). I personally don't see any point in manually setting the HEAD (I have never done so), but that's just me, others might. Cheers. -- Felipe Contreras
