Re: "git rebase" behavior change in 2.26.0

[Jeff King <peff@peff.net>]

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

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