Re: [RFC 2/2] pull: default pull.ff to "only" when pull.rebase is not set either

From: Alex Henrie <alexhenrie24@gmail.com>
Date: Dec 11, 2020, 20:38 UTC
Message-ID: <CAMMLpeQA7VW_C4yw_8n6j_SCoGr8k4VUOUaEp98UxUAMR6-MVw@mail.gmail.com>
In-Reply-To: <xmqqmtyviq9e.fsf@gitster.c.googlers.com>

On Wed, Dec 2, 2020 at 7:21 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

>
> So, the idea is that we currently return NULL when pull.ff is set,
> but now we also check "pull.rebase" etc. and give "--ff-only" when
> we did not choose --[no-]rebase and lack the configuration.  So the
> default (i.e. when pull.ff and pull.rebase are not set) would be as
> if the user said
>
>         git pull --ff-only --no-rebase
>
> I am not seeing what problem this tries to solve, exactly, though.
>
> I would have expected that for those who did not choose between
> merge and rebase (either with the pull.rebase configuration or from
> the command line --[no-]rebase option) the command would behave as
> if --ff-only is given, regardless of how pull.ff configuration is
> set.  That way, those who are unconfigured will just follow along
> what happens at the upstream, until they have their own development,
> at which point "--ff-only" can no longer be satisfied and their
> "pull" would fail until they choose how to consolidate their work
> with the upstream.

My goal was to make `git pull` without arguments and without any configuration set (the most common case) reject non-fast-forwards, and not add any new config variables or substantially change the semantics of the existing ones. In my opinion it's fine that setting pull.ff would change the behavior of `git pull` without arguments; I don't think that that would be bad behavior.

I am glad to see so much discussion surrounding the behavior of and documentation for `git pull`, but unfortunately at this point I'm having trouble following the discussion as a whole. I'm hoping that it settles down some so that it becomes more clear what I can do to help.

-Alex