From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 05 Feb 2025 13:08:57 GMT
Subject: Re: [PATCH] pull: allow branch.<name>.rebase to override pull.ff=only
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:

> 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.