Re: fc/pull-merge-rebase, was Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)

[Felipe Contreras <felipe.contreras@gmail.com>]

On Fri, Dec 11, 2020 at 5:32 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > On Thu, Dec 10, 2020 at 12:28 PM Junio C Hamano <gitster@pobox.com> wrote:
> > ...
> >> how much damage are we causing to
> >> existing users who expect the command to work the way it currently
> >> does?
> >
> > Zero. Because my proposal does *not* make the pull fail, it merely
> > prints a warning that it will change in the future.
>
> The approach to hold the "future" patch of and keep giving a
> "warning" is still likely to cause damage to people like Ted and
> Dscho (both gave examples of workflowsand automation that currently
> happily creating merges as the user expects, while the user just
> ignores the warning, without being configured at all), when finally
> the "future" patch (after fixing the test breakages, of course)
> lands.

That's right. But it doesn't have to land.

If after seeing the warning too many people complain about the
upcoming change, we can backtrack and decide not to pull the trigger.

> They just ignored the current loud messages---I do not see
> any reason to expect the updated "warning" would have any effect on
> them and help them to prepare for the future default change.

Nobody has offered them the chance to set "pull.mode=ff-only".

So how do you know they will not take the offer of something they
haven't been offered yet?

There's only one way to know.

> It is either being dishonest or deliberatly closing eyes to say
> "Zero" after hearing what they said, I would have to say.

It is a fact that a different warning (which is what I'm proposing)
will not affect them. There's no two ways about it.

Moreover, Ts'o said that he is already typing "git pull --rebase", so
he won't be affected.

We can leave this warning indefinitely; one year, two years... until
v3.0 is released. As much time as is needed, and after ten years
decide we don't want to pull the trigger after all.

Take a look at what happened with `merge.defaultToUpstream`. You
introduced it in 2011 after others and I suggested it:

93e535a5b7 (merge: merge with the default upstream branch without
argument, 2011-03-23)

And it was not actually made the default until 2014:

a01f7f2ba0 (merge: enable defaulttoupstream by default, 2014-04-20)

But *only* after we were confident this is what users actually wanted.

This gives us the best of all worlds; 1) a configuration that is sane
and potentially most people want to use, and they can use, as an
opt-in, 2) a potential to flip the switch and make this behavior the
default any time we want (after it has been extensively tested), and
3) the potential to backtrack and leave it forever as an option, and
never make it a default.

Cheers.

-- 
Felipe Contreras