"Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes:
> 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.
> 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.
