threads / rfc / 17183

RFC patchMake the rebase edit mode really end up in an edit state

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

## tl;dr

55 messages between Jan 15, 2009 and Jan 18, 2009. Diffs are folded; open one to read it.

replies: 54people: 15as markdown or json

Anders Melchiorsen· Jan 15, 2009, 00:27 UTC · lore

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(-)
Show changes to 2 files +12 −27

Documentation/git-rebase.txt, git-rebase--interactive.sh

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
Junio C Hamano· Jan 15, 2009, 00:43 UTC · re: Anders Melchiorsen · lore

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

Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
Show 17 quoted lines
> 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 :-).

We may need a version bump to 1.7.0 to update the UI for this command, but please do test rigorously to build a stronger case for a saner UI.

I've always had trouble with the instruction we give for splitting one commit into two using the interactive rebase in the documentation, as it always had a strong "Huh?" effect on me when it suddenly starts talking about doing a "git reset HEAD^"; I suspect your change may improve this situation quite a bit.

Boyd Stephen Smith Jr.· Jan 15, 2009, 02:49 UTC · re: Junio C Hamano · lore

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

On Wednesday 14 January 2009, Junio C Hamano <gitster@pobox.com> wrote about 'Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state':

Show 14 quoted lines
>Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>> 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.
>>
>> 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.
>>
>> I expect this to not be acceptable due to compatibility concerns.
>
>We may need a version bump to 1.7.0 to update the UI for this command,
> but please do test rigorously to build a stronger case for a saner UI.

Instead of changing the meaning of edit, how about introducing a "replace" command?

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     
Miles Bader· Jan 15, 2009, 04:10 UTC · re: Boyd Stephen Smith Jr. · lore

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

"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
Show 5 quoted lines
>>We may need a version bump to 1.7.0 to update the UI for this command,
>> but please do test rigorously to build a stronger case for a saner UI.
>
> Instead of changing the meaning of edit, how about introducing a "replace" 
> command?

That seems like at best an awkward workaround, not a real solution to the problem, which is that the term "edit XXXX" suggests you're starting with XXXX and modifying it. The term "replace" by contrast, seems more to connote entirely removing XXXX and substituting something else.

[I do wonder how on earth the current awkward behavior was accepted in the first place...]

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I
Boyd Stephen Smith Jr.· Jan 15, 2009, 05:00 UTC · re: Miles Bader · lore

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

On Wednesday 14 January 2009, Miles Bader <miles@gnu.org> wrote about 'Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state':

Show 9 quoted lines
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>>>We may need a version bump to 1.7.0 to update the UI for this command,
>>> but please do test rigorously to build a stronger case for a saner UI.
>>
>> Instead of changing the meaning of edit, how about introducing a
>> "replace" command?
>
>That seems like at best an awkward workaround, not a real solution to
>the problem,

Actually, I think it's a better solution (or rather a solution to the real problem) because others have already said they like and expect the current edit behavior.

The "real problem" is you need different behavior for your interactive rebasing.

>which is that the term "edit XXXX" suggests you're starting 
>with XXXX and modifying it.

Exactly. "edit" is: While interactively rebuilding history (rebase -i), you get to the first place that commit existed and then modify it (commit --amend or other tools).

>The term "replace" by contrast, seems more 
>to connote entirely removing XXXX and substituting something else.

Exactly. "replace" is: While rebasing you stop just before the commit existed (changes are even staged) and decide to do something else (like using add -i and a few commit commands to split the thing up or whatever).

>[I do wonder how on earth the current awkward behavior was accepted in
>the first place...]

(Actually, I do too, but it's accepted and expected behavior now--good reason not to change it.)

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     
Junio C Hamano· Jan 15, 2009, 06:13 UTC · re: Miles Bader · lore

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

Miles Bader <miles@gnu.org> writes:
> [I do wonder how on earth the current awkward behavior was accepted in
> the first place...]

That's actually very easy to explain. Both the contributor and the maintainer were rather familiar with the workflow using tools before "rebase -i" appeared, and to them, editing an existing commit was equivalent to first plant yourself on the commit to be amended, issue "commit --amend", and continue on with other tasks (similarly, "picking" an existing commit is to cherry-pick the commit to the state whatever the previous sequence of commands left). In other words, they both thought in terms of the underlying command sequence and it did not appear unnatural at all to them.

Johannes Schindelin· Jan 15, 2009, 12:24 UTC · re: Miles Bader · lore

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

Hi,
On Thu, 15 Jan 2009, Miles Bader wrote:
> [I do wonder how on earth the current awkward behavior was accepted in 
> the first place...]

Thanks for the praise! It is always nice to hear that one's work is appreciated.

SZEDER Gábor· Jan 15, 2009, 15:35 UTC · re: Junio C Hamano · lore

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

On Wed, Jan 14, 2009 at 04:43:14PM -0800, Junio C Hamano wrote:
Show 5 quoted lines
> I've always had trouble with the instruction we give for splitting one
> commit into two using the interactive rebase in the documentation, as it
> always had a strong "Huh?" effect on me when it suddenly starts talking
> about doing a "git reset HEAD^"; I suspect your change may improve this
> situation quite a bit.

I think we might want do differentiate editing a commit (modifying either the commit message or the patch or both) or splitting a commit.

The first is served well with the current 'edit' rebase command IMHO. I don't really see the point of the additional 'git reset --soft HEAD^'.

 * If you want to edit the commit message only, then you are
   better off with 'git commit --amend', because it preserves the
   previous commit message.  But with 'git reset --soft HEAD^' and
   'git commit' the commit message is "lost"; you have to use 'git
   commit -c ORIG_HEAD' instead, which is not that straightforward
   (and we don't have completion support for it).
 * If you want to modify the patch, too, then you would have to use
   'git add' anyway, regardless of whether there was a 'git reset
   --soft HEAD^', or not.  The only benefit of that 'reset' I'm seeing
   is that in that case 'git diff --cached' would show all the changes
   that would be committed; without the 'reset' 'git diff --cached
   HEAD^' is needed.
   But I'm not sure whether that benefit would offset the confusion of
   one more rebase command with just slightly different meaning.

For the second we could introduce a new rebase command like 'split', which would do the same as 'edit' but would also perform that 'git reset HEAD^' mentioned in the documentation automatically. Or perhaps it could be called 'divide', since the 's' abbreviation for 'split' is already taken by 'squash'. (Or maybe use capital 'S' for 'split'? might be confusing...)

Regards, Gábor

Junio C Hamano· Jan 15, 2009, 22:09 UTC · re: SZEDER Gábor · lore

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

SZEDER Gábor <szeder@ira.uka.de> writes:
Show 13 quoted lines
> I think we might want do differentiate editing a commit (modifying
> either the commit message or the patch or both) or splitting a commit.
>
> The first is served well with the current 'edit' rebase command IMHO.
> I don't really see the point of the additional 'git reset --soft
> HEAD^'.
>
>  * If you want to edit the commit message only, then you are
>    better off with 'git commit --amend', because it preserves the
>    previous commit message.  But with 'git reset --soft HEAD^' and
>    'git commit' the commit message is "lost"; you have to use 'git
>    commit -c ORIG_HEAD' instead, which is not that straightforward
>    (and we don't have completion support for it).

I agree that is a true disadvantage that shows "reset --soft HEAD^" is a bad idea (you could still say commit -c @{1}, though).

> For the second we could introduce a new rebase command like 'split',
> which would do the same as 'edit' but would also perform that 'git
> reset HEAD^' mentioned in the documentation automatically.
Perhaps.  
Sverre Rabbelier· Jan 15, 2009, 22:20 UTC · re: Junio C Hamano · lore

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

On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> bad idea (you could still say commit -c @{1}, though).

But it's not: "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."

-- 
Cheers,

Sverre Rabbelier
SZEDER Gábor· Jan 15, 2009, 22:59 UTC · re: Sverre Rabbelier · lore

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

On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:
Show 8 quoted lines
> On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> > I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> > bad idea (you could still say commit -c @{1}, though).
> 
> But it's not:
> "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."

Indeed, but in this case the rebase process will continue after finishing the commit message. OTOH, with the current behaviour, you must do a 'git commit --amend && git rebase --continue', which might seem more complicated at first sight, but...

But the current behaviour of the 'edit' rebase command gives you the possibility of adding further commits on top of the selected one (after you have edited that or left intact, doesn't matter). To do that with this automatic 'reset --soft HEAD^' modification you would first need to 'git commit -c @{1}' to keep the selected commit before going on with adding further commits, which is not quite nice.

Regards, Gábor

Björn Steinbrink· Jan 16, 2009, 00:11 UTC · re: SZEDER Gábor · lore

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

On 2009.01.15 23:59:12 +0100, SZEDER Gábor wrote:
Show 14 quoted lines
> On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:
> > On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> > > I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> > > bad idea (you could still say commit -c @{1}, though).
> > 
> > But it's not:
> > "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."
> 
> Indeed, but in this case the rebase process will continue after
> finishing the commit message.  OTOH, with the current behaviour, you
> must do a 'git commit --amend && git rebase --continue', which might
> seem more complicated at first sight, but...

No, you don't have to do that. As long as you only want to "edit" the commit you marked as "edit", you only need to use "git add" and "git rebase --continue". rebase -i checks whether HEAD still resolves to the same commit and if so, it automatically does the soft reset for you.

Maybe we should just advertise that in the message provided by rebase after it stops? I'm afraid I can't come up with a sane wording though, as there are still cases when you need to commit yourself, eg. when you use reset. And getting that into one simple sentence seems a bit hard (for me).

A bit off-topic: The "auto-amend" code path passes --no-verify to git commit. What's the reason for doing that? I actually always expected that to use my pre-commit hook to stop me from committing crap. :-/

Björn
Johannes Schindelin· Jan 16, 2009, 01:34 UTC · re: Björn Steinbrink · lore

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

Hi,
On Fri, 16 Jan 2009, Björn Steinbrink wrote:
> A bit off-topic: The "auto-amend" code path passes --no-verify to git 
> commit. What's the reason for doing that? I actually always expected 
> that to use my pre-commit hook to stop me from committing crap. :-/

IIRC people requested that rebase commits their crap without complaining :-)

Ciao, Dscho

Anders Melchiorsen· Jan 18, 2009, 01:24 UTC · re: Björn Steinbrink · lore

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

Björn Steinbrink <B.Steinbrink@gmx.de> writes:
Show 11 quoted lines
> No, you don't have to do that. As long as you only want to "edit"
> the commit you marked as "edit", you only need to use "git add" and
> "git rebase --continue". rebase -i checks whether HEAD still
> resolves to the same commit and if so, it automatically does the
> soft reset for you.
>
> Maybe we should just advertise that in the message provided by
> rebase after it stops? I'm afraid I can't come up with a sane
> wording though, as there are still cases when you need to commit
> yourself, eg. when you use reset. And getting that into one simple
> sentence seems a bit hard (for me).

I was happy to learn that trick when looking at the source, so I agree that it is a good idea to advertise it. You are right that it is hard to describe well in few words, though. Does somebody feel like repainting this?

Show changes to git-rebase--interactive.sh +4 −5
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -336,14 +336,13 @@ do_next () {
 		make_patch $sha1
 		git rev-parse --verify HEAD > "$DOTEST"/amend
 		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 amend the commit now, by marking"
+		warn "paths with 'git add <paths>' and running"
 		warn
 		warn "	git rebase --continue"
 		warn
+		warn "If you want to create new commits, run"
+		warn "'git commit' yourself before continuing."
 		exit 0
 		;;
 	squash|s)
Junio C Hamano· Jan 16, 2009, 01:09 UTC · re: SZEDER Gábor · lore

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

SZEDER Gábor <szeder@ira.uka.de> writes:
Show 6 quoted lines
> But the current behaviour of the 'edit' rebase command gives you the
> possibility of adding further commits on top of the selected one
> (after you have edited that or left intact, doesn't matter).  To do
> that with this automatic 'reset --soft HEAD^' modification you would
> first need to 'git commit -c @{1}' to keep the selected commit before
> going on with adding further commits, which is not quite nice.
Yeah, I agree.

I think my confusion mostly came from perception, and the way the "edit" action is (not) explained.

What "edit" means is "pick this commit and then stop to give control back to the user. The user is free to muck with the history starting from the state after picking the named commit in any way, and --continue will carry on the rest of the insns from the state" [*1*]. Once I realize that, it becomes clear what it means to do any of the following when "edit" gives the control back to me:

 (1) commit --amend (with or without changing the tree and message); this
     is the originally intended usage.  Edit the commit the machinery just
     picked and let it continue.  The end result is as if you edited one
     commit in the sequence.
 (2) making completely unrelated commits on top of the state "edit" gave
     you; this inserts a new commit in the sequence.
 (3) first "reset HEAD^", commit selected parts of the difference in one
     commit, commit the reaminder in another commit; this splits the
     commit the machinery just picked into two.

By the way, "rebase --continue" codepath has extra code that does something magical when the index does not match the HEAD commit. I suspect what it does makes sense only in the originally intended usage sequence (i.e. "edit" stops, you want to do "commit --amend" and then "rebase --continue" but somehow you forgot to commit everything).

How well does that logic work when the user wanted to do (2) or (3) above, and happened to have the index unclean when s/he said "rebase --continue"? Does it do something nonsensical?

[Footnote]

*1* Explained the same way, "pick" is "cherry-pick the named commit to replay its effect and then continue".

Johannes Schindelin· Jan 16, 2009, 12:10 UTC · re: Junio C Hamano · lore

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

Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
Show 16 quoted lines
>  (2) making completely unrelated commits on top of the state "edit" gave
>      you; this inserts a new commit in the sequence.
> 
>  (3) first "reset HEAD^", commit selected parts of the difference in one
>      commit, commit the reaminder in another commit; this splits the
>      commit the machinery just picked into two.
> 
> By the way, "rebase --continue" codepath has extra code that does
> something magical when the index does not match the HEAD commit.  I
> suspect what it does makes sense only in the originally intended usage
> sequence (i.e. "edit" stops, you want to do "commit --amend" and then
> "rebase --continue" but somehow you forgot to commit everything).
> 
> How well does that logic work when the user wanted to do (2) or (3) above,
> and happened to have the index unclean when s/he said "rebase --continue"?
> Does it do something nonsensical?

AFAICT the special handling is the only sane way to cope with (2) and (3), if it is the special handling that I am talking about:

If the current HEAD differs with the HEAD just after dropping to the shell, rebase --continue will _not_ just commit with the recorded information and continue.

The intended effect is that when you split a commit and continue with uncommitted changes, it will not just go ahead and call an editor with the original commit message: this message is now likely wrong.

It will only call an editor with the original message as a convenience when you did changes, but did not commit at all before continuing. Just a convenience I found quite useful.

Ciao, Dscho

Stephan Beyer· Jan 15, 2009, 00:49 UTC · re: Anders Melchiorsen · lore

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

Hi,
Anders Melchiorsen wrote:
> 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.

I think I like it and I think it's not the first time this comes up on the list. (Not sure, and too lazy to grab the archives.)

Also, in the design process of "git-sequencer" we (at least my mentors and I) discussed about doing this ("edit" vs "pause"), too, but it is always bad to change behavior many people are used, too. But sequencer instructions support options. So this could be solved as an option for "edit", e.g. "edit --no-commit" (or "edit -n").

So I'm writing this on my TODO list for the time after sequencer is merged into git...

Regards,
  Stephan
-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
Johannes Schindelin· Jan 15, 2009, 00:53 UTC · re: Anders Melchiorsen · lore

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

Hi,
On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
> 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.

Maybe, maybe not. I frequently rebase with "edit" when I actually mean "stop" (but "s" was taken from "squash" already). Then I test things, possibly fixing them.

So in that case, I do not want a git reset --soft HEAD^.

In any case, there is a pretty obvious difference between a merge conflict and a stop at "edit": the latter even shows you a pretty verbose explanation what to do next.

I also have to admit that it escapes me why you would want to force a new commit if nothing was changed to begin with.

However, I often would like to have "amend message" or some such, and I remember having seen patches, but I do not remember why they did not make it in.

Ciao, Dscho

Johannes Sixt· Jan 15, 2009, 07:35 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin schrieb:
Show 11 quoted lines
> On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
>> 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.
> 
> Maybe, maybe not.  I frequently rebase with "edit" when I actually mean 
> "stop" (but "s" was taken from "squash" already).  Then I test things, 
> possibly fixing them.
> 
> So in that case, I do not want a git reset --soft HEAD^.
Absolutely! I use "edit" for this purpose as well quite frequently.
-- Hannes
Johan Herland· Jan 15, 2009, 10:01 UTC · re: Johannes Sixt · lore

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

On Thursday 15 January 2009, Johannes Sixt wrote:
Show 14 quoted lines
> Johannes Schindelin schrieb:
> > On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
> >> 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.
> >
> > Maybe, maybe not.  I frequently rebase with "edit" when I actually mean
> > "stop" (but "s" was taken from "squash" already).  Then I test things,
> > possibly fixing them.
> >
> > So in that case, I do not want a git reset --soft HEAD^.
>
> Absolutely! I use "edit" for this purpose as well quite frequently.
What about providing both options?

"modify" does the "git reset --soft HEAD^" (Anders' suggestion) "amend" requires a "git commit --amend" (current behaviour) "edit" == "amend", but is deprecated and goes away in the future

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Sverre Rabbelier· Jan 15, 2009, 11:52 UTC · re: Johan Herland · lore

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

On Thu, Jan 15, 2009 at 11:01, Johan Herland <johan@herland.net> wrote:
> "modify" does the "git reset --soft HEAD^" (Anders' suggestion)
> "amend" requires a "git commit --amend" (current behaviour)

Why have amend do the same as edit? If you add an 'amend' one instead make it drop you into an editor to change the commit message. That's a workflow I often use. Often times I do not have a proper commit message when I commit (sometimes it is the result of "git commit -a -m "tmp"). To me having an 'amend' command that allows one to edit the commit message would make sense a lot :).

> "edit" == "amend", but is deprecated and goes away in the future
And as such, have edit do what it currently does.
-- 
Cheers,

Sverre Rabbelier
Johannes Schindelin· Jan 15, 2009, 12:36 UTC · re: Sverre Rabbelier · lore

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

Hi,
On Thu, 15 Jan 2009, Sverre Rabbelier wrote:
> On Thu, Jan 15, 2009 at 11:01, Johan Herland <johan@herland.net> wrote:
> > "modify" does the "git reset --soft HEAD^" (Anders' suggestion)
I could live with "modify".
Show 12 quoted lines
> > "amend" requires a "git commit --amend" (current behaviour)
> 
> Why have amend do the same as edit? If you add an 'amend' one instead
> make it drop you into an editor to change the commit message. That's a
> workflow I often use. Often times I do not have a proper commit
> message when I commit (sometimes it is the result of "git commit -a -m
> "tmp"). To me having an 'amend' command that allows one to edit the
> commit message would make sense a lot :).
> 
> > "edit" == "amend", but is deprecated and goes away in the future
> 
> And as such, have edit do what it currently does.
FWIW I fully agree.

If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more intuitive).

However, for the same reason (is it intuitive?) I am not fully convinced of 'amend' either. Because --amend _can_ mean that you change the diff of the commit. Maybe 'correct', 'redact' or 'rephrase'?

BTW I was not fully happy with 'edit' back then, either, which is the reason why I showed the usage in the comment _above_ the commit list. But nobody could suggest a name that I found convincingly better.

Ciao, Dscho

Adeodato Simó· Jan 15, 2009, 12:44 UTC · re: Johannes Schindelin · lore

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

* Johannes Schindelin [Thu, 15 Jan 2009 13:36:10 +0100]:
> However, for the same reason (is it intuitive?) I am not fully convinced 
> of 'amend' either.  Because --amend _can_ mean that you change the 
> diff of the commit.
Right.
> Maybe 'correct', 'redact' or 'rephrase'?
editmsg?
-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
He who has not a good memory should never take upon himself the trade of lying.
                -- Michel de Montaigne
Sverre Rabbelier· Jan 15, 2009, 13:41 UTC · re: Johannes Schindelin · lore

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

On Thu, Jan 15, 2009 at 14:41, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 5 quoted lines
> On Thu, 15 Jan 2009, Adeodato Simó wrote:
>> editmsg?
>
> Has the same first letter as 'edit'.  Would be confusing with the shortcut
> 'e', no?
"msgedit" with shortcut 'm'?
-- 
Cheers,

Sverre Rabbelier
Stephan Beyer· Jan 15, 2009, 13:57 UTC · re: Sverre Rabbelier · lore

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

Hi,
Sverre Rabbelier wrote:
Show 6 quoted lines
> >> editmsg?
> >
> > Has the same first letter as 'edit'.  Would be confusing with the shortcut
> > 'e', no?
> 
> "msgedit" with shortcut 'm'?
*sigh* If I was just not so late with sequencer...
There it is "pick -e" (or "pick --edit").
Regards,
  Stephan
-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
Johannes Schindelin· Jan 15, 2009, 14:02 UTC · re: Stephan Beyer · lore

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

Hi,
On Thu, 15 Jan 2009, Stephan Beyer wrote:
Show 11 quoted lines
> Sverre Rabbelier wrote:
> > >> editmsg?
> > >
> > > Has the same first letter as 'edit'.  Would be confusing with the shortcut
> > > 'e', no?
> > 
> > "msgedit" with shortcut 'm'?
> 
> *sigh* If I was just not so late with sequencer...
> 
> There it is "pick -e" (or "pick --edit").
... which obviously shares all the shortcomings of "edit".

Ciao, Dscho

Adeodato Simó· Jan 15, 2009, 13:43 UTC · re: Johannes Schindelin · lore

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

* Johannes Schindelin [Thu, 15 Jan 2009 14:41:14 +0100]:
> Hi,
> On Thu, 15 Jan 2009, Adeodato Simó wrote:
> > editmsg?
> Has the same first letter as 'edit'.  Would be confusing with the shortcut 
> 'e', no?

Yes, you are right. I always write the full word myself, so I forgot abbreviations are supported and commonly used.

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
A lie can go round the world before the truth has got its boots on.
                -- Terry Pratchett
Sverre Rabbelier· Jan 15, 2009, 12:45 UTC · re: Johannes Schindelin · lore

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

On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more
> intuitive).

Examine suggests that you cannot change the commit (you can look, but don't touch it!), no?

> However, for the same reason (is it intuitive?) I am not fully convinced
> of 'amend' either.  Because --amend _can_ mean that you change the
> diff of the commit.  Maybe 'correct', 'redact' or 'rephrase'?

OTOH, when you have no changes staged "git commit --ammend" will do exactly that, it will let you edit the commit message of the last commit.

> BTW I was not fully happy with 'edit' back then, either, which is the
> reason why I showed the usage in the comment _above_ the commit list.  But
> nobody could suggest a name that I found convincingly better.

The coder's law #349: "The hardest part of writing new functionality is coming up with a proper name that everyone agrees on".

-- 
Cheers,

Sverre Rabbelier
Johannes Schindelin· Jan 15, 2009, 13:42 UTC · re: Sverre Rabbelier · lore

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

Hi,
On Thu, 15 Jan 2009, Sverre Rabbelier wrote:
Show 7 quoted lines
> On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more
> > intuitive).
> 
> Examine suggests that you cannot change the commit (you can look, but
> don't touch it!), no?

So if you want to look but don't touch it, you can do exactly that. Brilliant, isn't it?

Ciao, Dscho

Sverre Rabbelier· Jan 15, 2009, 13:56 UTC · re: Johannes Schindelin · lore

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

On Thu, Jan 15, 2009 at 14:42, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> So if you want to look but don't touch it, you can do exactly that.
> Brilliant, isn't it?

Yes, ofcourse, but the current edit does allow you to modify (with 'git commit --amend')... I agree with Johan Herland though, Bikeshedding ftw :).

-- 
Cheers,

Sverre Rabbelier
Junio C Hamano· Jan 15, 2009, 16:59 UTC · re: Sverre Rabbelier · lore

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

"Sverre Rabbelier" <srabbelier@gmail.com> writes:
Show 7 quoted lines
> On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more
>> intuitive).
>
> Examine suggests that you cannot change the commit (you can look, but
> don't touch it!), no?

'stop' would be closest to what it currently does. It stops and it is up to you how to screw up the result ;-).

Sverre Rabbelier· Jan 15, 2009, 17:16 UTC · re: Junio C Hamano · lore

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

On Thu, Jan 15, 2009 at 17:59, Junio C Hamano <gitster@pobox.com> wrote:
> 'stop' would be closest to what it currently does.  It stops and it is up
> to you how to screw up the result ;-).

Hmmm, yes, I think that would be a better alias; but I think I like the idea to wait for changes like this till sequencer goes in, mhh?

-- 
Cheers,

Sverre Rabbelier
Johannes Schindelin· Jan 15, 2009, 18:21 UTC · re: Junio C Hamano · lore

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

Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
Show 12 quoted lines
> "Sverre Rabbelier" <srabbelier@gmail.com> writes:
> 
> > On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> >> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more
> >> intuitive).
> >
> > Examine suggests that you cannot change the commit (you can look, but
> > don't touch it!), no?
> 
> 'stop' would be closest to what it currently does.  It stops and it is up
> to you how to screw up the result ;-).
But it shares the first letter with 'squash'.

Ciao, Dscho

Johan Herland· Jan 15, 2009, 18:46 UTC · re: Johannes Schindelin · lore

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

On Thursday 15 January 2009, Johannes Schindelin wrote:
Show 5 quoted lines
> On Thu, 15 Jan 2009, Junio C Hamano wrote:
> > 'stop' would be closest to what it currently does.  It stops and it
> > is up to you how to screw up the result ;-).
>
> But it shares the first letter with 'squash'.
Personally, I'd rather use "pause", but that is taken as well.
Other suggestions:

wait yield rest timeout

..Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Anders Melchiorsen· Jan 15, 2009, 18:53 UTC · re: Johan Herland · lore

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

Johan Herland <johan@herland.net> writes:
Show 15 quoted lines
> On Thursday 15 January 2009, Johannes Schindelin wrote:
>> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>> > 'stop' would be closest to what it currently does.  It stops and it
>> > is up to you how to screw up the result ;-).
>>
>> But it shares the first letter with 'squash'.
>
> Personally, I'd rather use "pause", but that is taken as well.
>
> Other suggestions:
>
> wait
> yield
> rest
> timeout
break
Anders.
Johannes Schindelin· Jan 15, 2009, 19:28 UTC · re: Anders Melchiorsen · lore

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

Hi,
On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
> break

As rebase -i is just a loop of cherry-picks, as a C programmer I would think: "does this break out of the loop"?

Ciao, Dscho

Wincent Colaiuta· Jan 15, 2009, 19:27 UTC · re: Johan Herland · lore

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

El 15/1/2009, a las 19:46, Johan Herland escribió:
Show 15 quoted lines
> On Thursday 15 January 2009, Johannes Schindelin wrote:
>> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>>> 'stop' would be closest to what it currently does.  It stops and it
>>> is up to you how to screw up the result ;-).
>>
>> But it shares the first letter with 'squash'.
>
> Personally, I'd rather use "pause", but that is taken as well.
>
> Other suggestions:
>
> wait
> yield
> rest
> timeout
Perhaps stating the obvious, but:
wait - best suggestion so far, seeing as we can't use "stop"

yield - might sound intuitive to a Ruby programmer; but for others it's probably not so obvious as "yield" has a number of meanings in normal English similar to "give up", "give over" etc

rest - not quite as good as "wait"; machines wait for humans, but the never need to rest

timeout - sounds like an error condition, so not really appropriate

Sorry for participating in the painting. Just thought that "wait" was good enough to merit some positive feedback.

Cheers, Wincent

Jay Soffian· Jan 15, 2009, 20:26 UTC · re: Wincent Colaiuta · lore

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

On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com> wrote:
> wait - best suggestion so far, seeing as we can't use "stop"
This is a fun game. I like the color "halt".
j.
Wincent Colaiuta· Jan 15, 2009, 21:58 UTC · re: Jay Soffian · lore

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

El 15/1/2009, a las 21:26, Jay Soffian escribió:
Show 5 quoted lines
> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com>  
> wrote:
>> wait - best suggestion so far, seeing as we can't use "stop"
>
> This is a fun game. I like the color "halt".
Ooh, yes. An even better color.
Wincent
Johan Herland· Jan 16, 2009, 09:50 UTC · re: Jay Soffian · lore

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

On Thursday 15 January 2009, Jay Soffian wrote:
> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta <win@wincent.com> wrote:
> > wait - best suggestion so far, seeing as we can't use "stop"
> This is a fun game. I like the color "halt".
Nice. I like this one as well.

After some more thinking (triggered by Junio's recent post in another subthread), it occured to me that the current behaviour (currently known as "edit") is not something that is applied to one of the commits in the rebase list per se, but rather something that affects the rebase machinery *between* commits. So instead of

	edit e8902c1 Foo
we should consider something like
	pick e8902c1 Foo
	halt

which I think better encapsulates the current behaviour. (IOW, insert "halt" wherever you'd like to muck about with the history; e.g. doing "commit --amend", inserting extra commits, etc.)

We can then make shortcuts for common actions:
	amend e8902c1 Foo

does a "pick" followed by "commit --amend" (for editing the commit message), followed by "rebase --continue". Finally, we implement Anders' suggestion:

	modify e8902c1 Foo

(or whatever synonym for "edit" we converge on) does a "pick" followed by a "reset --soft HEAD^", followed by a "halt".

Have fun!
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Anders Melchiorsen· Jan 16, 2009, 10:27 UTC · re: Johan Herland · lore

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

Johan Herland wrote:
Show 6 quoted lines
> 	edit e8902c1 Foo
>
> we should consider something like
>
> 	pick e8902c1 Foo
> 	halt

Of all the suggestions, I like this one the most. Also, when placed like this, I am suddenly no longer opposed to the word "halt".

> 	amend e8902c1 Foo
>
> does a "pick" followed by "commit --amend" (for editing the commit
> message), followed by "rebase --continue".

I do not think that "amend" is the best word for editing only the commit message. A "commit --amend" can also make a new tree, so reusing the word with a different meaning could be bad.

As for alternatives, however, I can only come up with "copyedit", and that is so horrible that I will not even propose it :-)

Cheers, Anders.

Johan Herland· Jan 16, 2009, 10:58 UTC · re: Anders Melchiorsen · lore

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

On Friday 16 January 2009, Anders Melchiorsen wrote:
Show 12 quoted lines
> Johan Herland wrote:
> > 	amend e8902c1 Foo
> >
> > does a "pick" followed by "commit --amend" (for editing the commit
> > message), followed by "rebase --continue".
>
> I do not think that "amend" is the best word for editing only the
> commit message. A "commit --amend" can also make a new tree, so
> reusing the word with a different meaning could be bad.
>
> As for alternatives, however, I can only come up with "copyedit", and
> that is so horrible that I will not even propose it :-)
"rephrase"?
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
SZEDER Gábor· Jan 16, 2009, 12:42 UTC · re: Johan Herland · lore

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

On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
Show 15 quoted lines
> On Friday 16 January 2009, Anders Melchiorsen wrote:
> > Johan Herland wrote:
> > > 	amend e8902c1 Foo
> > >
> > > does a "pick" followed by "commit --amend" (for editing the commit
> > > message), followed by "rebase --continue".
> >
> > I do not think that "amend" is the best word for editing only the
> > commit message. A "commit --amend" can also make a new tree, so
> > reusing the word with a different meaning could be bad.
> >
> > As for alternatives, however, I can only come up with "copyedit", and
> > that is so horrible that I will not even propose it :-)
> 
> "rephrase"?
This is the first one that I found acceptable.

'amend', 'modify' and 'edit' are just too close and non-intuitive: they don't indicate _what_ will be amended, modified or edited at all.

'rephrase', on the other hand, is better, as you can rephrase a commit message, but it's weird to say "rephrase the patch". But it's still not as to-the-point as 'editmsg' (but that one has conflicting abbreviation).

Best, Gábor

Johannes Schindelin· Jan 16, 2009, 12:57 UTC · re: SZEDER Gábor · lore

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

Hi,
On Fri, 16 Jan 2009, SZEDER Gábor wrote:
Show 5 quoted lines
> On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
> 
> > "rephrase"?
> 
> This is the first one that I found acceptable.

I assume you missed http://article.gmane.org/gmane.comp.version-control.git/105783 in all that bikeshedding?

Ciao, Dscho

SZEDER Gábor· Jan 16, 2009, 13:27 UTC · re: Johannes Schindelin · lore

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

On Fri, Jan 16, 2009 at 01:57:57PM +0100, Johannes Schindelin wrote:
Show 13 quoted lines
> Hi,
> 
> On Fri, 16 Jan 2009, SZEDER Gábor wrote:
> 
> > On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
> > 
> > > "rephrase"?
> > 
> > This is the first one that I found acceptable.
> 
> I assume you missed 
> http://article.gmane.org/gmane.comp.version-control.git/105783 in all that 
> bikeshedding?

Yes, I indeed missed that. And still think that 'rephrase' is best among all the suggestions for this "edit just the commit message" thing. ('editmsg' conflicts; 'amend', 'modify', and 'correct' are not obvious enough (they don't clearly indicate what will be modified); and I'm not sure about 'redact', but I don't really like it because I had to look it up in the dictionary first).

Best, Gábor

Wincent Colaiuta· Jan 16, 2009, 14:28 UTC · re: SZEDER Gábor · lore

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

El 16/1/2009, a las 14:27, SZEDER Gábor escribió:
Show 22 quoted lines
> On Fri, Jan 16, 2009 at 01:57:57PM +0100, Johannes Schindelin wrote:
>> Hi,
>>
>> On Fri, 16 Jan 2009, SZEDER Gábor wrote:
>>
>>> On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:
>>>
>>>> "rephrase"?
>>>
>>> This is the first one that I found acceptable.
>>
>> I assume you missed
>> http://article.gmane.org/gmane.comp.version-control.git/105783 in  
>> all that
>> bikeshedding?
>
> Yes, I indeed missed that.  And still think that 'rephrase' is best
> among all the suggestions for this "edit just the commit message"
> thing.  ('editmsg' conflicts; 'amend', 'modify', and  'correct' are
> not obvious enough (they don't clearly indicate what will be
> modified); and I'm not sure about 'redact', but I don't really like it
> because I had to look it up in the dictionary first).
Two more colors for consideration:
   - "msg"/"msgedit"/"message" or similar
   - "reword"

I agree with Gábor that options like "modify" aren't clear because there's nothing in them that suggests that they're intended to operate on the commit _message_.

Wincent
Sverre Rabbelier· Jan 16, 2009, 13:12 UTC · re: Johan Herland · lore

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

On Fri, Jan 16, 2009 at 10:50, Johan Herland <johan@herland.net> wrote:
> we should consider something like
>        pick e8902c1 Foo
>        halt

I very much like this suggestion, Stephan, is this somewhat similar to how git sequencer will do things?

-- 
Cheers,

Sverre Rabbelier
Stephan Beyer· Jan 16, 2009, 17:26 UTC · re: Sverre Rabbelier · lore

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

Hi,
Sverre Rabbelier wrote:
Show 7 quoted lines
> On Fri, Jan 16, 2009 at 10:50, Johan Herland <johan@herland.net> wrote:
> > we should consider something like
> >        pick e8902c1 Foo
> >        halt
> 
> I very much like this suggestion, Stephan, is this somewhat similar to
> how git sequencer will do things?
Yes, it is
	pick e8902c1 # Foo
	pause

in sequencer currently. Of course, "pause" could be renamed to "halt", "stop" or whatever you like. But I think everyone likes something different.

And
	edit e8902c1 # Foo

is simply a shortcut for the pick-pause above. (Or "e e8902c1" instead of edit, which works, too.)

I usually prefer typing "cw edit<ESC>" over "o pause<ESC>" into vim in such cases.

Regards,
  Stephan
-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
Johannes Schindelin· Jan 16, 2009, 21:06 UTC · re: Stephan Beyer · lore

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

Hi,
On Fri, 16 Jan 2009, Stephan Beyer wrote:
> Of course, "pause" could be renamed to "halt", "stop" or whatever you 
> like. But I think everyone likes something different.
Both 's' and 'p' shortcuts are already taken, unfortunately.

Ciao, Dscho

Pieter de Bie· Jan 15, 2009, 12:52 UTC · re: Johannes Schindelin · lore

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

On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:
Show 8 quoted lines
> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be  
> more
> intuitive).
>
> However, for the same reason (is it intuitive?) I am not fully  
> convinced
> of 'amend' either.  Because --amend _can_ mean that you change the
> diff of the commit.  Maybe 'correct', 'redact' or 'rephrase'?

I think this demonstrates that you can do a lot more with 'edit' than just edit. 'redact' etc also don't cover it. Perhaps just a general 'pause' or something?

You can then put something like 'pause -- pause, for example to amend commit' in the description part.

Sverre Rabbelier· Jan 15, 2009, 12:55 UTC · re: Pieter de Bie · lore

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

On Thu, Jan 15, 2009 at 13:52, Pieter de Bie <pieter@frim.nl> wrote:
Show 8 quoted lines
> I think this demonstrates that you can do a lot more with 'edit' than just
> edit.
> 'redact' etc also don't cover it. Perhaps just a general 'pause' or
> something?
>
> You can then put something like 'pause  --  pause, for example to amend
> commit'
> in the description part.

That makes sense, perhaps we could name the feature described by the OP something like "reset", as that is what it actually does?

-- 
Cheers,

Sverre Rabbelier
Pieter de Bie· Jan 15, 2009, 12:57 UTC · re: Johannes Schindelin · lore

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

On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:
> BTW I was not fully happy with 'edit' back then, either, which is the
> reason why I showed the usage in the comment _above_ the commit  
> list.  But
> nobody could suggest a name that I found convincingly better.

(BTW, I reply to this thread because I'm also often confused with the rebase. The thing that hits me most is that with resolving conflicts, you have to do a 'git commit' and with 'edit', you have to do a 'git commit --amend'. This can get confusing if you set up an interactive rebase where you have some new picks or squashes, and also an edit. If the rebase stops, you first have to carefully read whether you're supposed to do a 'git commit' or a 'git commit --amend', and remember that until you're finished with the changes).

- Pieter
Björn Steinbrink· Jan 15, 2009, 13:46 UTC · re: Pieter de Bie · lore

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

On 2009.01.15 12:57:04 +0000, Pieter de Bie wrote:
Show 16 quoted lines
>
> On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:
>
>> BTW I was not fully happy with 'edit' back then, either, which is the
>> reason why I showed the usage in the comment _above_ the commit list.  
>> But
>> nobody could suggest a name that I found convincingly better.
>
> (BTW, I reply to this thread because I'm also often confused with the
> rebase. The thing that hits me most is that with resolving conflicts,
> you have to do a 'git commit' and with 'edit', you have to do a 'git
> commit --amend'. This can get confusing if you set up an interactive
> rebase where you have some new picks or squashes, and also an edit.
> If the rebase stops, you first have to carefully read whether you're
> supposed to do a 'git commit' or a 'git commit --amend', and remember
> that until you're finished with the changes).

You can handle both cases with: git add -u # Or whatever git rebase --continue

Only when you split a commit, you have to explicitly reset and commit.
Björn
Johan Herland· Jan 15, 2009, 13:54 UTC · re: Sverre Rabbelier · lore

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

On Thursday 15 January 2009, Sverre Rabbelier wrote:
Show 5 quoted lines
> On Thu, Jan 15, 2009 at 11:01, Johan Herland wrote:
> > "modify" does the "git reset --soft HEAD^" (Anders' suggestion)
> > "amend" requires a "git commit --amend" (current behaviour)
>
> Why have amend do the same as edit?

The names I chose are somewhat arbitrary, since we obviously have to keep on bikeshedding until we have something everybody can agree to.

However, my rationale was that IMO the word "edit" more closely matches Anders' suggestion, and is therefore somewhat misleading as a description of the current behaviour. But we obviously cannot change the meaning of "edit" without upsetting current users. Therefore, introduce "amend" to more accurately describe the current behaviour. As for "modify", it was simply the best synonym for "edit" I could find.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net

← back to recent threads