Re: [PATCH] pull: allow branch.<name>.rebase to override pull.ff=only

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2025, 13:08 UTC
Message-ID: <xmqqbjvgr11y.fsf@gitster.g>
In-Reply-To: <20250205030642.95252-1-ben.knoble+github@gmail.com>

"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:

Show 11 quoted lines

> When running "git pull" with the following configuration options, we
> fail to merge divergent branches:
>
> - pull.ff=only
> - pull.rebase (unset)
> - branch.<current_branch>.rebase=true
>
> Yet it seems that the user intended to make rebase the default for the
> current branch while using --ff-only for non-rebase pulls. Since this
> case appears uncovered by existing tests, changing the behavior here
> might be safe: it makes what was an error into a successful rebase.

Hmph, to me it looks more like with pull.ff, the user, no matter what other variables say and which mode between merge and rebase a pull consolidates the histories, wanted to make sure they will never accept anything other than fast-forwarding of the history, because the end-user expects that they will pull only after they push out everything, i.e., the expectation is that the other side is a strict fast-forward or the user wants to examine the situation before making further damage to the local history.

With that understanding, I am not sure "even though pull.ff tells us to stop unless the other side is a descendant of our history, if we are rebasing, it is OK if they have something we have never seen" is a good thing to do.

So, I dunno.