On Wed Nov 20, 2024 at 02:00, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Bence Ferdinandy" <bence@xxxxxxxxxxxxxx> writes: > >> Your suggestion seems to be the original tri-state configuration that came up >> in one of the original discussions. It was recently requested again for fetch >> to just do this automatically >> (https://lore.kernel.org/git/CAAHKNRGv19rhnqCkJMpE2FomNQBHvSS36aC=fh0UwO+9-6RRfA@xxxxxxxxxxxxxx), >> so at least some people would like to have this fully automated. > > And that is *not* the only option, and I am trying to help others > by preventing unconditional warning messages from annoying them. > >> On the other hand: considering your points in the linked very early discussion, >> maybe "warn" would be a better default? > > Those who want to stick to their manual choice would have to do an > explicit set-head once, whether the default is "true" or "warn", so > their inconvenience would not affect the choice of the default. > > I think "warn" is a good default _only_ for folks who want to verify > and then expect they will follow what the upstream does 99% of the > time. For them, when they do not want to switch to what the > upstream says (which is the rest 1%), there is no good way to > squelch the warning other than dropping the configuration, but then > they will lose the ability to notice further flips at the remote > after that, which may turn out to be a problem. > > Instead of "true", "warn", and "false", we might need "if it is set > to _this_ value, do not warn and keep the current setting" to help > those who cautiously only allow the remote affect what they use > after inspecting, but expect that the choice made by the remote will > not be outrageous most of the time for them. > > If we want to solve this completely for them, that is. I dunno. I initially thought you meant a fourth setting here, but what you are suggesting here is that in case the user has "remote.origin.followremotehead = never" set even in case of "init && remote add && fetch" HEAD should not be created, which is a bit different, because originally we discussed only not changing after the initial creation. This makes a lot of sense. > > Those who want to blindly follow what the upstream says 100% of the > time will have to switch to "true" just once manually, if the > default were "warn", but once may be one time too many for them. > > And that is why I said "clone" (and "fetch" setting a non-existing > HEAD automatically) may want to default to "true". Fair point again. > >> Fair point. >> >> This series has a tendency for growing in complication in each iteration :) > > Anytime somebody gets swayed by an opinion to add unconditional > warning or unconditional futzing without considering that such a > move may annoy some users that are different from the opinion giver, > we need to make sure there are escape hatches. Under the assumption > that most projects only flip HEAD very rarely, and considering the > fact that we have lived with manual setting with set-head and > nothing else, we could drop the automatic setting by "fetch" > altogether to reduce the scope of the series without losing much > *and* more importantly without harming existing users. Don't get me wrong, I'd like to do the right thing here, and appreciate that my perspective is rather limited. I was just reflecting on the fact that the first "working" version of the series was only two patches. Writing this is fun and educational for me. > > I think we could make it a multi-step transition in order to keep > changes to "git fetch" we make in each step smaller, which may go > like so: That being said, if it's possible to graduate a part of the series when it's ready and where it makes sense to split, that would be welcome. As you write below the first such place would be remote set-head --auto. Not that that is ready yet, I need to fix the mistake you spotted, update a commit message, and add a test-coverage. But in that case I might send a v14 with just these updates and work on getting the fetch settings in parallel for a v15. Technically I would just need to build the series off next for a while, right? > > 1) Let "git fetch" create missing remotes/$name/HEAD. No other > changes. So this is a bit simpler version of what we have now (as long as it doesn't bother for example you, that there is a state which will create HEAD without being able to disable it :)) Should this even print anything? Probably not, clone also doesn't tell you that the HEAD was set. > > 2) Introduce a remote.$name.followRemoteHEAD that can say "the last > branch we observed that they point at is 'main'". Set it when > we clone, When "git fetch" notices that the remote flipped its > HEAD to a different value, warn and update (which would give us > the "warn only once, do not annoy users by constantly warning"). > The user can delete the configuration to squelch "git fetch" (in > other words, the repository does not remember the last setting, > so we refrain from warning "it has changed since the last time"). > No other changes. > > 3) Allow remote.$name.followRemoteHEAD to be set to > > 3-a) "always", which would squelch the warning and causes "git > fetch" to always repoint the local remotes/$name/HEAD to > whatever the remote says, But this should print similar messages as remote set-head --auto when there is an actual change done, right? And should probably respect --quiet? > > 3-b) "warn", which would cause "git fetch" to warn when the > remote's HEAD is different from local remotes/$name/HEAD, This should also respect --quite I assume. > > 3-c) "never", which would cause "git fetch" to even omit the > "copy if it does not exist" we add in 1) to help those who > deliberately want to keep remotes/$name/HEAD missing (to force > themselves to be more explicit, saying things like "git checkout > -b topic origin/maint" and "git rebase origin/master", but never > "git checkout --detach origin"). I think skipping 2 and jumping straight to the final configuration would be easier, no need to wrap one's head around a configuration state that will essentially never really exist and most of the extra complexity (at least from my perspective) comes from having to have a configuration at all. Thanks, Bence
