Re: [PATCH] pull: avoid running both merge and rebase

>
> On Fri, Mar 27, 2020 at 09:51:40PM +0000, Elijah Newren via GitGitGadget wrote:
>
> > When opt_rebase is true, we still first check if we can fast-forward.
> > If the branch is fast-forwardable, then we can avoid the rebase and just
> > use merge to do the fast-forward logic.  However, when commit a6d7eb2c7a
> > ("pull: optionally rebase submodules (remote submodule changes only)",
> > 2017-06-23) added the ability to rebase submodules it accidentally
> > caused us to run BOTH a merge and a rebase.  Add a flag to avoid doing
> > both.
> >
> > This was found when a user had both pull.rebase and rebase.autosquash
> > set to true.  In such a case, the running of both merge and rebase would
> > cause ORIG_HEAD to be updated twice (and match HEAD at the end instead
> > of the commit before the rebase started), against expectation.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> >     pull: avoid running both merge and rebase
> >
> >     Cc: Norbert Kiesel nkiesel@gmail.com [nkiesel@gmail.com], Jeff King
> >     peff@peff.net [peff@peff.net]
>
> I'm not sure how cc is supposed to work with GGG, but it clearly didn't
> here. :)

> Anyway, the patch looks good. Thanks for following through on this.
>
> > @@ -992,10 +993,12 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
> >                       if (is_descendant_of(merge_head, list)) {
> >                               /* we can fast-forward this without invoking rebase */
> >                               opt_ff = "--ff-only";
> > +                             ran_ff = 1;
> >                               ret = run_merge();
> >                       }
> >               }
> > -             ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);
> > +             if (!ran_ff)
> > +                     ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);
>
> It feels like there should be some arrangement of the conditionals that
> doesn't require setting an extra flag, but I actually don't think there
> is. And anyway, doing the most obvious and minimal fix here is the right
> place to start. We don't need more regressions. ;)