Alex Henrie wrote: > On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: > > > > Alex Henrie wrote: > > > On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras > > > <felipe.contreras@xxxxxxxxx> 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
