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

[PATCH 2/2] rebase: write a reflog entry when finishing

From
Jeff King <peff@peff.net>
Date
May 27, 2011, 20:16 UTC
Message-ID
<20110527201614.GB29836@sigill.intra.peff.net>
In-Reply-To
<BANLkTinyKQJQUHa8tn43=cCJMsVbgaZXjA@mail.gmail.com>

When we finish a rebase, our detached HEAD is at the final result. We update the original branch ref with this result, and then point the HEAD symbolic ref at the updated branch. We write a reflog for the branch update, but not for the update of HEAD.

Because we're already at the final result on the detached HEAD, moving to the branch actually doesn't change our commit sha1 at all. So in that sense, a reflog entry would be pointless.

However, humans do read reflogs, and an entry saying "rebase finished: returning to refs/heads/master" can be helpful in understanding what is going on.

Signed-off-by: Jeff King <peff@peff.net>
---
See the minor test update for an example of how this could break people
or scripts who assume they know what's at which point in the reflog. In
general I think all bets are off with HEAD, because commands do their
work on a detached HEAD, and then provide a nice single-entry result in
the branch reflog (which is why I switched the test to use the more
stable master@{1}).
 git-rebase--interactive.sh    |    4 +++-
 git-rebase.sh                 |    4 +++-
 t/t3404-rebase-interactive.sh |    2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 41ba96a..65690af 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -510,7 +510,9 @@ do_next () {
 	refs/*)
 		message="$GIT_REFLOG_ACTION: $head_name onto $shortonto" &&
 		git update-ref -m "$message" $head_name $newhead $orig_head &&
-		git symbolic-ref HEAD $head_name
+		git symbolic-ref \
+		  -m "$GIT_REFLOG_ACTION: returning to $head_name" \
+		  HEAD $head_name
 		;;
 	esac && {
 		test ! -f "$state_dir"/verbose ||
diff --git a/git-rebase.sh b/git-rebase.sh
index 57cbe49..d7855ea 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -153,7 +153,9 @@ move_to_original_branch () {
 		message="rebase finished: $head_name onto $onto"
 		git update-ref -m "$message" \
 			$head_name $(git rev-parse HEAD) $orig_head &&
-		git symbolic-ref HEAD $head_name ||
+		git symbolic-ref \
+			-m "rebase finished: returning to $head_name" \
+			HEAD $head_name ||
 		die "Could not move back to $head_name"
 		;;
 	esac
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 7d8147b..47c8371 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -317,7 +317,7 @@ test_expect_success '--continue tries to commit' '
 '
 
 test_expect_success 'verbose flag is heeded, even after --continue' '
-	git reset --hard HEAD@{1} &&
+	git reset --hard master@{1} &&
 	test_tick &&
 	test_must_fail git rebase -v -i --onto new-branch1 HEAD^ &&
 	echo resolved > file1 &&
-- 
1.7.5.3.12.g99e25
Previous: Jeff KingNext: Jeff King
Message 7 of 11 in “git symbolic-ref vs. reflog (vs. rebase)”
  1. Csaba HenkApr 29, 2011
  2. Junio C HamanoApr 29, 2011
  3. Csaba HenkApr 29, 2011
  4. Jeff KingApr 30, 2011
  5. Csaba HenkMay 2, 2011
  6. 1/2 rebase: create HEAD reflog entry when abortingJeff King, May 27, 2011
  7. 2/2 rebase: write a reflog entry when finishingJeff King, May 27, 2011
  8. Jeff KingApr 29, 2011
  9. Junio C HamanoApr 29, 2011
  10. Jeff KingApr 30, 2011
  11. Csaba HenkMay 2, 2011

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.