Re: pull.rebase config option broken in 2.33.1

[Elijah Newren <newren@gmail.com>]

On Fri, Nov 26, 2021 at 9:05 PM Jeff King <peff@peff.net> wrote:
>
> On Fri, Nov 26, 2021 at 02:43:44PM -0800, Elijah Newren wrote:
>
> > On Fri, Nov 26, 2021 at 1:45 PM Jeff King <peff@peff.net> wrote:
> > >
> > > On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:
> > >
> > > > +cc Alex and Elijah from the original 3d5fc24dae (pull: abort if
> > > > --ff-only is given and fast-forwarding is impossible, 2021-07-21) in
> > > > case they have further thoughts, but I _think_ this is working as
> > > > designed.
> > >
> > > Whoops, forgot the cc. Original message in full below.
> >
> > I believe this was already fixed in 2.34.1 in commit ea1954af77
> > ("pull: should be noop when already-up-to-date", 2021-11-17).
>
> I thought that at first, too, but this case is a bit different:
>
> > > > In the bug I linked (and what got fixed in 2.34.1), the issue is that
> > > > when the local branch is ahead of the remote, we don't say "up to date",
> > > > but complain about fast-forwards.
> > > >
> > > > It's hard to tell from the output above, but it looks like you have a
> > > > case where there are new commits both locally and on the remote? In
> > > > which case a rebase would work just fine.
>
> I think the key thing here is that (AFAICT) the behavior is unchanged
> unless the user has set pull.ff=only explicitly.

Ah, I see there were two parts to their report, one of which is the
issue fixed in 2.34.1.  I'll respond to his original email and ask if
he has pull.ff=only set and explain how that interacts with
pull.rebase.