Re: pull.rebase config option broken in 2.33.1

From: Jeff King <peff@peff.net>
Date: Nov 27, 2021, 05:05 UTC
Message-ID: <YaG8gUnikxtQs5zx@coredump.intra.peff.net>
In-Reply-To: <CABPp-BGC5DrArqWMiwwpJQgK8WucVcAxj0Ptgpi+_KRb7V7Nwg@mail.gmail.com>

On Fri, Nov 26, 2021 at 02:43:44PM -0800, Elijah Newren wrote:

Show 13 quoted lines

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

Show 7 quoted lines

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

-Peff