Re: [PATCH v5 0/6] Reject non-ff pulls by default

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Junio C Hamano wrote:
> ...
>> Until the "--merge" option is added, "pull.mode = merge" cannot be
>> the same as "git pull --merge".  I think you either need to squash
>> these two steps into one, or flip the order of them.
>
> Yeah, but the documentation of --merge should mention `pull.mode` and
> `branch.<name>.pullmode`. If I do --merge first I would have to mention
> pull.rebase and branch.<name>.rebase, which is weird.

And the point of your step (1) to introduce pull.mode is to fix the
weirdness, so in that sense, it makes even more sense to do the
"--merge" first and then pull.mode the second.

If you first add --merge with an awkward documentation in the first
step and then correct that awkwardness in the second step that adds
pull.mode (oh, by the way, we need to pay attention to pull.rename
as a fallback at least for a while), that would show a clear
justification why pull.mode is a good idea.

> I think it's more sensible to do the less visible changes first.

The people who discover pull.mode and set it to "merge" will be
greeted with an error with that step.

So it appears that squashing these two (and possibly also the
addition of merge-ff-only) into a single step would be the only
alternative, if you want to avoid the "introduce something that
shows the awkwardness of the situation and immediately fix it"
approach.