Re: Pick the right default and stop warn on `git pull`

From: Theodore Y. Ts'o <tytso@mit.edu>
Date: Nov 23, 2020, 19:13 UTC
Message-ID: <20201123191355.GA132317@mit.edu>
In-Reply-To: <CAMMLpeRLsE=zNDjCRKmEMFxJBYcnTOdDGxEL9cZuVhuDMF=sLg@mail.gmail.com>

On Mon, Nov 23, 2020 at 10:59:13AM -0700, Alex Henrie wrote:

Show 14 quoted lines

> 
> Hi Vit, as the message explains, you can use `git config --global
> pull.rebase false` to permanently silence the warning for all of your
> repositories. The idea is that in a future version of Git, users will
> not be allowed to pull at all without specifying a reconciliation
> strategy. This will prevent users (novices in particular) from
> accidentally creating messes by merging branches that should have been
> rebased instead.
> 
> Personally, I would rather have pull.rebase be true by default (and
> I'm sure many others would like that too), but there are so many users
> who really do want to merge that it's not reasonable to make rebasing
> the default. The most reasonable solution is to ask the user to be
> explicit about what they want and not make assumptions.

It's really going to depend on your workflow. If your repository is used as a building point by other repositories, and you pull from the upstream repo, rebasing may cause a massive headache for your downstream "sub-maintainers" (assuming that you are a subsystem maintainer).

If your repository is effectively a leaf repo, then rebasing may be harmless, although there are still who don't like rebasing because it invalidates your previous testing. My personal preference is to do a git fetch, followed by a git merge --ff-only, and if that errors out, then I know I need to take a bit more care before deciding what to do next.

But everyone's workflow varies, which is why creating a default is going to controversial no matter what the default might be.

Cheers,

					- Ted