On Tue Nov 19, 2024 at 04:16, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Bence Ferdinandy <bence@xxxxxxxxxxxxxx> writes: > >> If the user has remote/HEAD set already and it looks like it has changed >> on the server, then print a message, otherwise set it if we can. > > The user uses remote/origin/HEAD to point at the "primary thing the > user is interested in at the remote 'origin'". "git clone" > propagates remote's HEAD to local because their HEAD is the opinion > of the remote which branch they want the users to consider the > primary thing. But the user can have valid reasons to consider a > branch different from what the remote suggests as the primary thing, > and an explicit "set-head" is a way to do so. > > After such a set-up is made and the user is perfectly happy, would > it make sense to repeatedly remind that their HEAD points at > something the user is not interested in? > > Perhaps it may make sense when given the "--verbose" option, or > after the first time the difference was noticed, but otherwise, I > suspect it becomes annoying to those who keep them deliberately > different from each other. > > I wonder if it is more sensible to automate for these two different > classes of users with a new configuration per remote. Since this discussion reaches a bit back I looked up the first message where the current behaviour was discussed, and where in the end it was said we don't need configuration (the very first implementation always updated HEAD). Starting here: https://lore.kernel.org/git/xmqqseu7cfsl.fsf@gitster.g/ That being said: Your suggestion seems to be the original tri-state configuration that came up in one of the original discussions. It was recently requested again for fetch to just do this automatically (https://lore.kernel.org/git/CAAHKNRGv19rhnqCkJMpE2FomNQBHvSS36aC=fh0UwO+9-6RRfA@xxxxxxxxxxxxxx), so at least some people would like to have this fully automated. > > - When "git clone" initially sets up, or "git remote set-head > --auto" matches the local to the remote, we set the new > "remote.$name.autoUpdateHEAD" configuration variable to true. I think this is a good default. -> Coming back here I think "warn" is a better default see below. > > - When "git remote set-head" explicitly sets remote/$name/HEAD > to some value (if we can detect the case where it is different > from what the remote has, that would be a plus, but it incurrs > network traffic, so care must be taken to design this part), we > drop the "remote.$name.autoUpdateHEAD" configuration variable, > if and only if it is set to true. I also agree with this. I don't think it would be necessary to do a network check at this point. If somebody is deliberately changing the remote head manually, they are probably aware of the current situation and can always set their configuration to "warn" if they care, or just check manually once in a while. At least I feel needing network connection to do this would be more a hindrance than useful. > > - When remote.$name.autoUpdateHEAD configuration is true, "git > fetch" automatically matches remote/$name/HEAD to what the HEAD > at the remote points at. If remote.$name.autoUpdateHEAD is set > to some other value (e.g., "warn"), show the warning so that the > user can choose to do "git remote set-head" to a specific value > (which would not drop the remote.$name.autoUpdateHEAD set to > "warn") or "git remote set-head --auto" (which would start to > follow whatever remote uses). Make sense. One thing you haven't mentioned is when you start locally with git init && git remote add && git fetch. But since this whole series started by wanting to make this the same as cloning I assume it should be "true" as well. In fact, if the default behaviour is true this would just work. On the other hand: considering your points in the linked very early discussion, maybe "warn" would be a better default? I'm not sure. Most people would not see warnings anyway since I doubt a) many users change their remote/HEAD manually or b) many projects change their HEAD at all or if they do, more than once. Gaving "true" as default would change the current behaviour with silently updating existing remote/HEADs. The warning could also tell them that `remote set-head --auto` will set this to automatic in the future as well and thus remove any warnings or that if they know what they want the can set it to false. > > With something like the above, those who just want to follow along > would get remote.$name.autoUpdateHEAD=true and silently follow > along, while those who want to explicitly control would be able to > do so. I dunno, but I am fairly negative on a persistent warning > message that tells the user that the only normal case is to have > remote/origin/HEAD point at the same branch the remote's HEAD points > at. Fair point. This series has a tendency for growing in complication in each iteration :) Best, Bence
