Re: "git rebase" behavior change in 2.26.0

From: Jeff King <peff@peff.net>
Date: Mar 26, 2020, 07:28 UTC
Message-ID: <20200326072840.GA2198456@coredump.intra.peff.net>
In-Reply-To: <CABPp-BFMN+pnOjEe2tZZJp3_Noojn5j1ip3dh8Xz9hCZoKJbxw@mail.gmail.com>

On Wed, Mar 25, 2020 at 11:32:31PM -0700, Elijah Newren wrote:

Show 20 quoted lines

> > Say, WAT?!?  This attempted to run both a merge and a rebase?  That
> > appears to be yet another bug.
> 
> From git-pull.c:
> 
>     ...
>         if (is_descendant_of(merge_head, list)) {
>             /* we can fast-forward this without invoking rebase */
>             opt_ff = "--ff-only";
>             ret = run_merge();
>         }
>     }
>     ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);
> 
> Perhaps that comment should read:
> 
>    /* we can fast-forward this using merge and avoid rebase...but then
> run rebase afterward anyway! */
> 
> Whoops.  Perhaps fixing this is a good micro-project candidate?  Too small?

Good find. :) Looks like this is due to a6d7eb2c7a (pull: optionally rebase submodules (remote submodule changes only), 2017-06-23) which changed the early return to "ret =".

I think it would be an OK size for a micro-project, but it seems like a bug which we may want fixed sooner rather than waiting for somebody to pick it up from the micro-project pile.

Or perhaps not. AFAICT this has been there for 2+ years without anybody noticing.

-Peff