"Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes: > Hmm. After a bit more thought: running `remote set-head` doesn't make much > sense if you have "always" and makes a bit of sense if you have "warn". Yeah, after "warn" tells the user what branch the remote points at, the user may decide to match. Or the user may decide to flip the remote-tracking HEAD to something unrelated. In the former case, the next and subsequent fetch will not warn, until the remote flips the HEAD again. In the latter case, the next and subsequent fetch will warn, until they happen to change their HEAD again and their choice happens to match ours. > So > maybe one thing set-head could do is _if_ you have always it could drop you to > "warn" and "warn" could also include a line not just about following with > "remote set-head" but something like "You can either follow with set-head, or > you can turn this off but still get a warning if origin changes by setting > ...". Hmph, if you've been happy with "always", if we notice that the remote flipped its HEAD, we switch to "warn" and the next and subsequent fetch will not warn, until they flip again, and then we will keep warning. If you do not want to follow (but still monitor origin), the above would not be sufficient, unless "by setting..." part gives a new choice via your .followRemoteHEADManual setting. >> 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. > > Good idea. Probably shorter though like "warn-if-not-$branch". Sorry, I wasn't offering an alternative I thought was better. It was "we could do this, if we really want to avoid two variables". But thinking about it further, not having to worry about two variables may be a huge benefit. If you set .followRemoteHEAD to "manual" and .followRemoteHEADManual to some value, and then changed .followRemoteHEAD to something else, you may be very likely to forget unsetting .followRemoteHEADManual that is no longer in effect. >> I do not think any of the above should block this topic. It can be >> added later without disrupting all other modes implemented there. > > Ack, I'll send a respin with just enum fixed for now. Thanks.
