Re: [PATCH v13 8/9] fetch: set remote/HEAD if it does not exist

[Junio C Hamano <gitster@pobox.com>]

Bence Ferdinandy <bence@ferdinandy.com> 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.