Re: [PATCH 2/2] pull: improve default warning

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

Alex Henrie wrote:
> On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Alex Henrie wrote:
> > > On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras
> > > <felipe.contreras@gmail.com> wrote:
> > > >
> > > > +                "If unsure, run \"git pull --no-rebase\".\n"
> > >
> > > I don't think the message should recommend merging over rebasing;
> >
> > This is the default strategy.
> 
> Yes, but it shouldn't be,

Feel free to propose a patch to change that, in the meantime this is the
default.

> and we shouldn't make the problem worse by encouraging people to
> default to merging without thinking.

We are not.

> > > The eventual goal is to get rid of the default here and make the user
> > > make an educated choice, which does imply some work on the user's
> > > part, but it avoids the massive headaches created by users merging
> > > without understanding what they're doing.
> >
> > Indeed, but any minute change in git's UI is a gargantuan task that
> > takes several years--or even decades--to accomplish, if it ever happens.
> > I started this patch in 2013, and here we are.
> 
> Although what needs to be done had been envisioned by some as early as
> 2013, the warning has only been around since Git 2.27 (released in
> June 2020), and it was only restricted to pulls where fast-forwarding
> is impossible in Git 2.31 (released in March 2021). The good news is
> that (unless I'm mistaken) there are no more changes that need to be
> made prior to changing the message from from "advise" to "die".

There is *a lot* that needs to be done.

 1. Update the documentation
 2. Add a --merge option (instead of the ackward --no-rebase)
 3. Fix all the wrong behavior with --ff, --no-ff, and -ff-only
 4. Add a pull.mode configuration
 5. Add a configuration for the mode in which we want to die
 6. Fix inconsistencies in the UI

Only *then* can we even begin to throw a warning stating that the
default behavior might change in the future, and how to try the new
behavior.

> All that needs to be done is to set a date to make the switch.

No, there's a lot more.

> For comparison, users were given from Git 1.8 to Git 2.0 (October 2012
> to May 2014, 1 year and 7 months) to acclimate when push.default
> changed from "matching" to "simple".

We haven't told the users the default mode is going to change for a
single day. We don't have a configuration to tell them to turn on to
enable the new mode, nor do we have a configuration to tell them to
enable to stay in the old mode.

There's no configuration in git 2.32 that is equivalent to what I
proposed with pull.mode=fast-forward?


In the meantime there's no reason to have subpar documentation.

-- 
Felipe Contreras