summaryrefslogtreecommitdiff
path: root/builtin/pull.c
diff options
context:
space:
mode:
authorPhilippe Blain <levraiphilippeblain@gmail.com>2020-11-14 00:34:45 (GMT)
committerJunio C Hamano <gitster@pobox.com>2020-11-17 00:01:13 (GMT)
commit5176f20ffeab9c2bda6f93195096372364ec6f88 (patch)
treef53069c66faa693e4c01d508323f5438c53be994 /builtin/pull.c
parentf260c6b46c1ebb5b1b4dfffd8812b5416cfcc4e7 (diff)
downloadgit-5176f20ffeab9c2bda6f93195096372364ec6f88.zip
git-5176f20ffeab9c2bda6f93195096372364ec6f88.tar.gz
git-5176f20ffeab9c2bda6f93195096372364ec6f88.tar.bz2
pull: check for local submodule modifications with the right range
Ever since 'git pull' learned '--recurse-submodules' in a6d7eb2c7a (pull: optionally rebase submodules (remote submodule changes only), 2017-06-23), we check if there are local submodule modifications by checking the revision range 'curr_head --not rebase_fork_point'. The goal of this check is to abort the pull if there are submodule modifications in the local commits being rebased, since this scenario is not supported. However, the actual range of commits being rebased is not 'rebase_fork_point..curr_head', as the logic in 'get_rebase_newbase_and_upstream' reveals, it is 'upstream..curr_head'. If the 'git merge-base --fork-point' invocation in 'get_rebase_fork_point' fails to find a fork point between the current branch and the remote-tracking branch we are pulling from, 'rebase_fork_point' is null and since 4d36f88be7 (submodule: do not pass null OID to setup_revisions, 2018-05-24), 'submodule_touches_in_range' checks 'curr_head' and all its ancestors for submodule modifications. Since it is highly likely that there are submodule modifications in this range (which is in effect the whole history of the current branch), this prevents 'git pull --rebase --recurse-submodules' from succeeding if no fork point exists between the current branch and the remote-tracking branch being pulled. This can happen, for example, when the current branch was forked from a commit which was never recorded in the reflog of the remote-tracking branch we are pulling, as the last two paragraphs of the "Discussion on fork-point mode" section in git-merge-base(1) explain. Fix this bug by passing 'upstream' instead of 'rebase_fork_point' as the 'excl_oid' argument to 'submodule_touches_in_range'. Reported-by: Brice Goglin <bgoglin@free.fr> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/pull.c')
-rw-r--r--builtin/pull.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/builtin/pull.c b/builtin/pull.c
index 441e94a..ac40c43 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -1037,7 +1037,7 @@ int cmd_pull(int argc, const char **argv, const char *prefix)
if ((recurse_submodules == RECURSE_SUBMODULES_ON ||
recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND) &&
- submodule_touches_in_range(the_repository, &rebase_fork_point, &curr_head))
+ submodule_touches_in_range(the_repository, &upstream, &curr_head))
die(_("cannot rebase with locally recorded submodule modifications"));
if (!autostash) {
struct commit_list *list = NULL;