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. - 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. - 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. - 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). or something like that? 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. Thanks.
