Re: [PATCH v1] fetch: add configuration for set_head behaviour

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 28, 2024, 00:12 UTC
Message-ID: <xmqqplmgqkrr.fsf@gitster.g>
In-Reply-To: <D5X7DHD1BRYO.22CU1OL6KLN49@ferdinandy.com>

"Bence Ferdinandy" <bence@ferdinandy.com> writes:

Show 9 quoted lines

> Just to clarify, an example: the remote's HEAD is set to "master", and you have
> - git remote set-head origin next
> - git config set remote.origin.followRemoteHead "manual"
> - git config set remote.origin.followRemoteHeadManual "master"
>
> you manually set these explicitly. As long as the remote's HEAD is still
> "master" you do not get a warning when running fetch, but if it changes to
> something else (even "next"), you _do_ get a warning, that is not silenced
> until you set followRemoteHeadManual to "next".

Yup.

> Would you expect `git remote set-head origin next` to set followRemoteHead to
> "manual" and to set the correct value for the followRemoteHeadManual to
> "master" if it actually changed the current refs/remote/origin/HEAD from master
> to next?

What I found missing is:

    "I know this is the value I expect them to have, because it was
    the value I last observed there. Please let me know when they
    changed their mind; I want to reconsider my position when it
    happens, and your warning me would help me to do so."

My running "remote set-head" to manually change which of their branches I am interested in does not tell Git anything about what branch I expect them to be pointing at with HEAD. It may be the action after such "reconsideration" of my position, but there is 0 bit of information on what I expect their HEAD to be pointing at.

> Or is having this completely manual fine?

If it can be automated, that would be nicer, but I do not think a manual "remote set-head origin next" gives any information to help automating it.

Show 5 quoted lines

> I toyed with the thought of rolling the two settings together (an unrecognized
> string would mean the reference for which we must be silent), but then you
> couldn't have a remote/HEAD called "create" for example, so I think we need to
> store that separately. I'm also not quite happy with "followRemoteHeadManual"
> ...

Yeah, I was thinking a value like "warn-if-not-pointing-at-$branch" where $branch part would be a token like 'bc/set-head-symref', 'master', etc.

I do not think any of the above should block this topic. It can be added later without disrupting all other modes implemented there.

Thanks.