git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 2/2] pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches

From
Elijah Newren <newren@gmail.com>
Date
Aug 6, 2010, 14:05 UTC
Message-ID
<1281103503-27515-3-git-send-email-newren@gmail.com>
In-Reply-To
<1281103503-27515-1-git-send-email-newren@gmail.com>
Prior to c85c79279df2c8a583d95449d1029baba41f8660, pull --rebase would run
  git rebase $merge_head
which resulted in a call to
  git format-patch ... --ignore-if-in-upstream $merge_head..$cur_branch

This had two nice qualities when upstream isn't rebased: (1) "only" the patches in $merge_head..$cur_branch would be applied, and (2) patches could be dropped/ignored if they had already been applied. But this did not work well when upstream is rebased, since in that case $merge_head..$cur_branch refers to too many commits that would need to be reapplied, and could result in intentionally dropped commits being reintroduced.

So the algorithm was changed.  Defining $old_remote_ref to be the most
recent entry in the reflog for @upstream that is an ancestor of
$cur_branch, pull --rebase was changed (over time) to run
  git rebase --onto $merge_head $old_remote_ref
which results in a call to
  git format-patch ... --ignore-if-in-upstream $old_remote_ref..$cur_branch

In the rebased upstream case, this can result in far fewer commits being included in the rebase, though the fact that $old_remote_ref is an ancestor of $cur_branch means that format-patch will not know what upstream is and will not be able to determine if any patches are already upstream.

In the non-rebased upstream case, this new form is usually the same as the
original code.  However, as noted above, the --ignore-if-in-upstream flag
becomes meaningless and all patches will be forced to be reapplied.  Also,
$old_remote_ref can be an ancestor of
   $(git merge-base $merge_head $cur_branch)
meaning that pull --rebase may try to reapply more patches which are
clearly already upstream, without the means to detect that they've already
been applied.  This can be extremely confusing for new users ("git is
giving me lots of conflicts in stuff I didn't even change since my last
push.")

Fix the non-rebased upstream case by ignoring $old_remote_ref whenever it is contained by $(git merge-base $merge_head $cur_branch).

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 git-pull.sh     |   34 ++++++++++++++++++++++------------
 t/t5520-pull.sh |    4 ++--
 2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index a09a44e..54da07b 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -206,18 +206,6 @@ test true = "$rebase" && {
 		git diff-index --ignore-submodules --cached --quiet HEAD -- ||
 		die "refusing to pull with rebase: your working tree is not up-to-date"
 	fi
-	oldremoteref= &&
-	. git-parse-remote &&
-	remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
-	oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
-	for reflog in $(git rev-list -g $remoteref 2>/dev/null)
-	do
-		if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
-		then
-			oldremoteref="$reflog"
-			break
-		fi
-	done
 }
 orig_head=$(git rev-parse -q --verify HEAD)
 git fetch $verbosity $progress $dry_run --update-head-ok "$@" || exit 1
@@ -273,6 +261,28 @@ then
 	exit
 fi
 
+if test true = "$rebase"
+then
+	oldremoteref= &&
+	. git-parse-remote &&
+	remoteref="$(get_remote_merge_branch "$@" 2>/dev/null)" &&
+	oldremoteref="$(git rev-parse -q --verify "$remoteref")" &&
+	for reflog in $(git rev-list -g $remoteref 2>/dev/null)
+	do
+		if test "$reflog" = "$(git merge-base $reflog $curr_branch)"
+		then
+			oldremoteref="$reflog"
+			break
+		fi
+	done
+
+	o=$(git show-branch --merge-base $curr_branch $merge_head $oldremoteref)
+	if test "$oldremoteref" = "$o"
+	then
+		unset oldremoteref
+	fi
+fi
+
 merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
 case "$rebase" in
 true)
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 8f76829..4bf2253 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -182,7 +182,7 @@ test_expect_success 'setup for detecting upstreamed changes' '
 	)
 '
 
-test_expect_failure 'git pull --rebase detects upstreamed changes' '
+test_expect_success 'git pull --rebase detects upstreamed changes' '
 	(cd dst &&
 	 git pull --rebase &&
 	 test -z "$(git ls-files -u)"
@@ -212,7 +212,7 @@ test_expect_success 'setup for avoiding reapplying old patches' '
 	)
 '
 
-test_expect_failure 'git pull --rebase does not reapply old patches' '
+test_expect_success 'git pull --rebase does not reapply old patches' '
 	(cd dst &&
 	 (git pull --rebase || true) &&
 	 test 3 != $(find .git/rebase-apply -name "000*" | wc -l)
-- 
1.7.1.1
Previous: Elijah NewrenNext: Elijah Newren
Message 3 of 4 in “Fix spurious conflicts with pull --rebase”
  1. 0/2 Fix spurious conflicts with pull --rebaseElijah Newren, Aug 6, 2010
  2. 1/2 t5520-pull: Add testcases showing spurious conflicts from git pull --rebaseElijah Newren, Aug 6, 2010
  3. 2/2 pull --rebase: Avoid spurious conflicts and reapplying unnecessary patchesElijah Newren, Aug 6, 2010
  4. Elijah NewrenAug 8, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.