On Wed Nov 20, 2024 at 02:00, Junio C Hamano [off-list ref] wrote:

"Bence Ferdinandy" [off-list ref] writes:

quoted

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@mail.gmail.com (local)),
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.

quoted

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.

quoted

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