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

[RFC PATCH] Make the rebase edit mode really end up in an edit state

From
AMAnders Melchiorsen <mail@cup.kalibalik.dk>
Date
Jan 15, 2009, 00:27 UTC
Message-ID
<87ab9th0rh.fsf@cup.kalibalik.dk>

Previously, the interactive rebase edit mode placed the user after the commit in question. That was awkward because a commit is supposedly immutable. Thus, she was forced to use "git commit --amend" for her changes.

To improve on this UI, we now issue "git reset --soft HEAD^" before exiting to the user. This puts the changes in the index, editable in the Git sense. It also makes sure that a pre-filled editor is fired up when doing "git rebase --continue", in case the user just wanted to fix the commit message.

The revised UI is close to the situation in a merge/rebase conflict, and thus familiar to the user.

Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---

I always have a hard time figuring out what to do during an interactive rebase. Recently, it dawned on me that the reason is that I have to do different things: one thing when editing on purpose, and a different thing when resolving a conflict. So my fingers never learn.

With this change, I propose to make the UI more uniform. I think that the new way is more intuitive, too, if you will agree that a Git UI can be intuitive.

As I expect this to not be acceptable due to compatibility concerns, I have not tested it much. The patch is mostly to catch some attention, but I will be happy to complete it if there is interest in the change.

It was surprising for me to find the needed code already present. Now I know that I do not have to do "git commit --amend", it will happen automatically if I add some files. That trick alone is worth the time that I have spent on this :-).

Cheers, Anders.

 Documentation/git-rebase.txt |   10 ++++------
 git-rebase--interactive.sh   |   29 ++++++++---------------------
 2 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 32f0f12..3442a68 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -320,9 +320,8 @@ not look at them but at the commit names ("deadbee" and "fa1afe1" in this
 example), so do not delete or edit the names.
 
 By replacing the command "pick" with the command "edit", you can tell
-'git-rebase' to stop after applying that commit, so that you can edit
-the files and/or the commit message, amend the commit, and continue
-rebasing.
+'git-rebase' to stop after applying that commit. You are free to make
+further modifications before you continue rebasing.
 
 If you want to fold two or more commits into one, replace the command
 "pick" with "squash" for the second and subsequent commit.  If the
@@ -375,9 +374,8 @@ add other commits.  This can be used to split a commit into two:
 
 - Mark the commit you want to split with the action "edit".
 
-- When it comes to editing that commit, execute `git reset HEAD^`.  The
-  effect is that the HEAD is rewound by one, and the index follows suit.
-  However, the working tree stays the same.
+- When it comes to editing that commit, execute `git reset`.  The effect
+  is that the changes in the commit are now only in the working tree.
 
 - Now add the changes to the index that you want to have in the first
   commit.  You can use `git add` (possibly interactively) or
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bdec43c..0fe678f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -274,7 +274,7 @@ peek_next_command () {
 
 do_next () {
 	rm -f "$DOTEST"/message "$DOTEST"/author-script \
-		"$DOTEST"/amend || exit
+		|| exit
 	read command sha1 rest < "$TODO"
 	case "$command" in
 	'#'*|'')
@@ -294,13 +294,13 @@ do_next () {
 		pick_one $sha1 ||
 			die_with_patch $sha1 "Could not apply $sha1... $rest"
 		make_patch $sha1
-		git rev-parse --verify HEAD > "$DOTEST"/amend
+		git reset --soft HEAD^ ||
+			die "Cannot rewind the HEAD"
 		warn "Stopped at $sha1... $rest"
-		warn "You can amend the commit now, with"
 		warn
-		warn "	git commit --amend"
-		warn
-		warn "Once you are satisfied with your changes, run"
+		warn "You can edit the commit now. When you are satisfied,"
+		warn "mark the corrected paths with 'git add <paths>', and"
+		warn "then run"
 		warn
 		warn "	git rebase --continue"
 		warn
@@ -442,22 +442,9 @@ do
 		else
 			. "$DOTEST"/author-script ||
 				die "Cannot find the author identity"
-			amend=
-			if test -f "$DOTEST"/amend
-			then
-				amend=$(git rev-parse --verify HEAD)
-				test "$amend" = $(cat "$DOTEST"/amend) ||
-				die "\
-You have uncommitted changes in your working tree. Please, commit them
-first and then run 'git rebase --continue' again."
-				git reset --soft HEAD^ ||
-				die "Cannot rewind the HEAD"
-			fi
 			export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
-			git commit --no-verify -F "$DOTEST"/message -e || {
-				test -n "$amend" && git reset --soft $amend
+			git commit --no-verify -F "$DOTEST"/message -e ||
 				die "Could not commit staged changes."
-			}
 		fi
 
 		require_clean_work_tree
@@ -590,7 +577,7 @@ first and then run 'git rebase --continue' again."
 #
 # Commands:
 #  p, pick = use commit
-#  e, edit = use commit, but stop for amending
+#  e, edit = use commit, but stop for editing
 #  s, squash = use commit, but meld into previous commit
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
-- 
1.6.0.2.514.g23abd3
Next: Junio C Hamano
Message 1 of 55 in “Make the rebase edit mode really end up in an edit state”
  1. Make the rebase edit mode really end up in an edit stateAnders Melchiorsen, Jan 15, 2009
  2. Junio C HamanoJan 15, 2009
  3. Boyd Stephen Smith Jr.Jan 15, 2009
  4. Miles BaderJan 15, 2009
  5. Boyd Stephen Smith Jr.Jan 15, 2009
  6. Junio C HamanoJan 15, 2009
  7. Johannes SchindelinJan 15, 2009
  8. SZEDER GáborJan 15, 2009
  9. Junio C HamanoJan 15, 2009
  10. Sverre RabbelierJan 15, 2009
  11. SZEDER GáborJan 15, 2009
  12. Björn SteinbrinkJan 16, 2009
  13. Johannes SchindelinJan 16, 2009
  14. Anders MelchiorsenJan 18, 2009
  15. Junio C HamanoJan 16, 2009
  16. Johannes SchindelinJan 16, 2009
  17. Stephan BeyerJan 15, 2009
  18. Johannes SchindelinJan 15, 2009
  19. Johannes SixtJan 15, 2009
  20. Johan HerlandJan 15, 2009
  21. Sverre RabbelierJan 15, 2009
  22. Johannes SchindelinJan 15, 2009
  23. Adeodato SimóJan 15, 2009
  24. Johannes SchindelinJan 15, 2009
  25. Sverre RabbelierJan 15, 2009
  26. Stephan BeyerJan 15, 2009
  27. Johannes SchindelinJan 15, 2009
  28. Adeodato SimóJan 15, 2009
  29. Sverre RabbelierJan 15, 2009
  30. Johannes SchindelinJan 15, 2009
  31. Sverre RabbelierJan 15, 2009
  32. Junio C HamanoJan 15, 2009
  33. Sverre RabbelierJan 15, 2009
  34. Johannes SchindelinJan 15, 2009
  35. Johan HerlandJan 15, 2009
  36. Anders MelchiorsenJan 15, 2009
  37. Johannes SchindelinJan 15, 2009
  38. Wincent ColaiutaJan 15, 2009
  39. Jay SoffianJan 15, 2009
  40. Wincent ColaiutaJan 15, 2009
  41. Johan HerlandJan 16, 2009
  42. Anders MelchiorsenJan 16, 2009
  43. Johan HerlandJan 16, 2009
  44. SZEDER GáborJan 16, 2009
  45. Johannes SchindelinJan 16, 2009
  46. SZEDER GáborJan 16, 2009
  47. Wincent ColaiutaJan 16, 2009
  48. Sverre RabbelierJan 16, 2009
  49. Stephan BeyerJan 16, 2009
  50. Johannes SchindelinJan 16, 2009
  51. Pieter de BieJan 15, 2009
  52. Sverre RabbelierJan 15, 2009
  53. Pieter de BieJan 15, 2009
  54. Björn SteinbrinkJan 15, 2009
  55. Johan HerlandJan 15, 2009

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.