Re: Why does `pull.rebase` default to `false`?
- From
- Konstantin Tokarev <annulen@yandex.ru>
- Date
- Feb 28, 2020, 21:46 UTC
- Message-ID
- <1200001582926410@vla1-fadba9086fdf.qloud-c.yandex.net>
- In-Reply-To
- <CAHd499B3HbXPo+O3u3qA-SfJ_dV=z2k5v09mVHtbjXGkAaNBvQ@mail.gmail.com>
29.02.2020, 00:23, "Robert Dailey" <rcdailey.lists@gmail.com>:
Show 10 quoted lines
> On Fri, Feb 28, 2020 at 3:10 PM Konstantin Tokarev <annulen@yandex.ru> wrote: >> In reality, newbies often end up doing chaotic merges caused by pull >> instead of learning about rebase and branches. IMO, it would be better >> to have pull.ff=only as a default. > > You and Junio make a really good point. After reading the responses, I > definitely could reword my problem statement. The problem is that, for > newbie git users (the majority of people I work with), they just do > `git pull` which always does a merge. Myself (and many others) in > simple workflows don't like it when newbies do merges on a pull.
And if default behavior would suddenly be switched to pull.rebase=true, newbie who was doing these merges all the way may end up in a really nasty situation when doing pull: rebasing local master which may already contain a few local merges not present in origin/master, resulting in complete change of recent history shape and possibly some involving a few bad conflicts. Changing default to pull.ff=only seems to be less likely to wreak havoc.
Show 6 quoted lines
> > So the problem statement is: Prevent newbies from doing a merge commit > on pull. Whether its a rebase or not is beside the point. I think > making it --ff-only would solve the issue nicely. It forces them to > make their intention explicit: Ether do a merge pull, or a rebase > pull. But you are forcing them to pick (and ultimately get educated).
-- Regards, Konstantin