On Mon, Dec 7, 2020 at 1:53 PM Junio C Hamano [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

They start by saying the same thing. But one errors out and says the
user must choose, and the other warns that in the future the user must
choose.

Then I do not see the point in giving the warning---even in the
future they do not have to choose as long as they are merely
following along.

They don't. With my patch series they see the warning only when the
pull is non-fast-forward.

quoted

quoted

quoted

Just to put this series in context: it's only part 1; it does not
introduce pull.mode, and it doesn't make --ff-only the default.

I'd view the "in a non-fast-forward situation, the warning kicks in
to those who haven't chosen between merge and rebase (i.e. no
pull.rebase set to either true or false, and pull.ff not set to
only), which is a bit more gentle than the current situtation" a
good stopping point.  That state is already making ff-only the
default for unconfigured users, or you can view it as shipping "git
pull" in a shape that has the more dangerous half of its feature
disabled to avoid hurting users.  So I am not sure why you keep
saying you do not have --ff-only as the default.

The warning doesn't make the pull fail, ff-only does.

Then probably you are giving an error and a warning at a wrong
place.

 - When history fast-forwards, and the user hasn't chosen between
   rebase or merge, there is no need to give any warning.  Just
   succeed by fast-forwarding.

Yes. That's what my patch [1] in this series does.

 - When history does not fast-forward and the user hasn't chosen
   between rebase or merge, whether pull.ff is set to "only" or not,
   we should fail and the error message can instruct the user to
   choose between rebase and merge; there is no "ff-only" option
   that is useful in the situation.

Yes. *Eventually*, that's part 3.

And that essentially makes the "ff-only" mode the safe default that
castrates one half of the feature (the more dangerous half) of "git
pull".  Why do we make it more complicated than that by warning that
the user must choose in the future?  They will see an error tell
them that when they start pulling while on their own work, and I do
not see a need to bother them before that point.

Because the amount of time users have seen the correct error message
telling them about this upcoming change is *zero*.

No one is aware of this backwards-incompatible change that is
upcoming, since the current warning message doesn't specify any such
future change.

Moreover, no one has configured their pull.mode, because no one has
seen the message that tells them to do so.

And no one has had time to try out the upcoming "pull.mode=ff-only".
They haven't had time to find bugs on it, or weird interactions, or
suggestions how to improve it. Because the code has not been deployed,
and no warning has told them to tentatively enable that mode.

When the default for push.default was changed, it was a good thing
that we gave users (and ourselves) a grace period to try it out before
permanently flipping the switch. The transition went smoothly.

I think the progression of the warning is hard to see from all the
patch series. I'm sending all my patches and I will explain in a
timeline how it progresses until eventually we reach the desired end
goal.

Cheers.

[1] https://lore.kernel.org/git/20201204061623.1170745-8-felipe.contreras@gmail.com/ (local)

-- 
Felipe Contreras