pull: avoid running both merge and rebase

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> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Elijah Newren committed Mar 27, 2020 at 21:51 UTC fbae70ddc6da7df3f901d95da2b11b2cb58c8a29

1 file changed +4 -1

builtin/pull.c

+4 -1

@@ -986,6 +986,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)

986

987 if (opt_rebase) {

988 int ret = 0;

989 + int ran_ff = 0;

990 if ((recurse_submodules == RECURSE_SUBMODULES_ON ||

991 recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND) &&

992 submodule_touches_in_range(the_repository, &rebase_fork_point, &curr_head))

@@ -1002,10 +1003,12 @@ int cmd_pull(int argc, const char **argv, const char *prefix)

1003 if (is_descendant_of(merge_head, list)) {

1004 /* we can fast-forward this without invoking rebase */

1005 opt_ff = "--ff-only";

1006 + ran_ff = 1;

1007 ret = run_merge();

1008 }

1009 }

1008 - ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);

1010 + if (!ran_ff)

1011 + ret = run_rebase(&curr_head, merge_heads.oid, &rebase_fork_point);

1012

1013 if (!ret && (recurse_submodules == RECURSE_SUBMODULES_ON ||

1014 recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND))