[PATCH] rebase -i: support single-letter abbreviations for the actions

[PATCH] rebase -i: support single-letter abbreviations for the actions

[Johannes Schindelin]

When you do many rebases, you can get annoyed by having to type out
the actions "edit" or "squash" in total.

This commit helps that, by allowing you to enter "e" instead of "edit",
or "s" instead of "squash", and it also plays nice with "merge" or "amend"
as synonyms to "squash".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 git-rebase--interactive.sh |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 823291d..0f9483e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -232,14 +232,14 @@ do_next () {
 	'#'*|'')
 		mark_action_done
 		;;
-	pick)
+	pick|p)
 		comment_for_reflog pick
 
 		mark_action_done
 		pick_one $sha1 ||
 			die_with_patch $sha1 "Could not apply $sha1... $rest"
 		;;
-	edit)
+	edit|e)
 		comment_for_reflog edit
 
 		mark_action_done
@@ -254,7 +254,7 @@ do_next () {
 		warn
 		exit 0
 		;;
-	squash)
+	squash|s|merge|m|amend|a)
 		comment_for_reflog squash
 
 		has_action "$DONE" ||
@@ -263,7 +263,7 @@ do_next () {
 		mark_action_done
 		make_squash_message $sha1 > "$MSG"
 		case "$(peek_next_command)" in
-		squash)
+		squash|s|merge|m|amend|a)
 			EDIT_COMMIT=
 			USE_OUTPUT=output
 			cp "$MSG" "$SQUASH_MSG"
-- 
1.5.3.2.1102.g9487

Re: [PATCH] rebase -i: support single-letter abbreviations for the actions

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> When you do many rebases, you can get annoyed by having to type out
> the actions "edit" or "squash" in total.
>
> This commit helps that, by allowing you to enter "e" instead of "edit",
> or "s" instead of "squash", and it also plays nice with "merge" or "amend"
> as synonyms to "squash".

I am not sure if we want to taint the words merge and amend like
this.  I was hoping someday you would allow people to reorder
something like this...

          e
           \     
 ---a---b---c---d

into something like this:

      e
       \     
 ---b'--c'--a'+d'

The insn sequence you prepare for the user to edit would be:

	pick	a	
	pick	b
	merge   c
        pick    d

and then the user would rewrite that to:

	pick	b
        merge   c
        pick    a
        squash  d

I do not think making 'amend' a synonym to 'squash' is correct
either; isn't it closer to 'edit'?

I however do agree that giving short-hand would be a good idea.
 

[PATCH v2] rebase -i: support single-letter abbreviations for the actions

[Johannes Schindelin]

When you do many rebases, you can get annoyed by having to type out
the actions "edit" or "squash" in total.

This commit helps that, by allowing you to enter "e" instead of "edit",
"p" instead of "pick", or "s" instead of "squash".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Fri, 28 Sep 2007, Junio C Hamano wrote:

	> I am not sure if we want to taint the words merge and amend like
	> this.  I was hoping someday you would allow people to reorder
	> something like this...

	Okay, you convinced me.

	> 
	>           e
	>            \     
	>  ---a---b---c---d
	> 
	> into something like this:
	> 
	>       e
	>        \     
	>  ---b'--c'--a'+d'

	I thought that this would be possible with "git rebase -p -i"?

	Ah no, that does not work; "-p" is not yet graceful enough to 
	accept reorders.  (But then, I do not see why the command should 
	be "merge" instead of the "pick" we already have...)

 git-rebase--interactive.sh |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 823291d..7a5aaa5 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -232,14 +232,14 @@ do_next () {
 	'#'*|'')
 		mark_action_done
 		;;
-	pick)
+	pick|p)
 		comment_for_reflog pick
 
 		mark_action_done
 		pick_one $sha1 ||
 			die_with_patch $sha1 "Could not apply $sha1... $rest"
 		;;
-	edit)
+	edit|e)
 		comment_for_reflog edit
 
 		mark_action_done
@@ -254,7 +254,7 @@ do_next () {
 		warn
 		exit 0
 		;;
-	squash)
+	squash|s)
 		comment_for_reflog squash
 
 		has_action "$DONE" ||
@@ -263,7 +263,7 @@ do_next () {
 		mark_action_done
 		make_squash_message $sha1 > "$MSG"
 		case "$(peek_next_command)" in
-		squash)
+		squash|s)
 			EDIT_COMMIT=
 			USE_OUTPUT=output
 			cp "$MSG" "$SQUASH_MSG"
-- 
1.5.3.2.1102.g9487

Re: [PATCH] rebase -i: support single-letter abbreviations for the actions

[Avi Kivity]

Johannes Schindelin wrote:
> When you do many rebases, you can get annoyed by having to type out
> the actions "edit" or "squash" in total.
>
> This commit helps that, by allowing you to enter "e" instead of "edit",
> or "s" instead of "squash", and it also plays nice with "merge" or "amend"
> as synonyms to "squash".
>
>   

Can we make "amend" like squash, except that it keeps the first commit's 
authorship instead of the second?  I often merge a commit with some 
minor fix that comes later, and usually want to keep the original author 
record.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [PATCH] rebase -i: support single-letter abbreviations for the actions

[Johannes Schindelin]

Hi,

On Sat, 29 Sep 2007, Avi Kivity wrote:

> Johannes Schindelin wrote:
> > When you do many rebases, you can get annoyed by having to type out 
> > the actions "edit" or "squash" in total.
> > 
> > This commit helps that, by allowing you to enter "e" instead of 
> > "edit", or "s" instead of "squash", and it also plays nice with 
> > "merge" or "amend" as synonyms to "squash".
> 
> Can we make "amend" like squash, except that it keeps the first commit's 
> authorship instead of the second?  I often merge a commit with some 
> minor fix that comes later, and usually want to keep the original author 
> record.

I do not necessarily think it is not doable, but I have different 
suggestion to you:

If you amend the commit with a minor fix that comes later, why not do 
"rebase -i" _before_ applying the fix, and then using "edit" on the 
respective commit?

That way you can even test the result easily, which you cannot do with 
"squash".

Ciao,
Dscho

Re: [PATCH] rebase -i: support single-letter abbreviations for the actions

[Avi Kivity]

Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Avi Kivity wrote:
>
>   
>> Johannes Schindelin wrote:
>>     
>>> When you do many rebases, you can get annoyed by having to type out 
>>> the actions "edit" or "squash" in total.
>>>
>>> This commit helps that, by allowing you to enter "e" instead of 
>>> "edit", or "s" instead of "squash", and it also plays nice with 
>>> "merge" or "amend" as synonyms to "squash".
>>>       
>> Can we make "amend" like squash, except that it keeps the first commit's 
>> authorship instead of the second?  I often merge a commit with some 
>> minor fix that comes later, and usually want to keep the original author 
>> record.
>>     
>
> I do not necessarily think it is not doable, but I have different 
> suggestion to you:
>
> If you amend the commit with a minor fix that comes later, why not do 
> "rebase -i" _before_ applying the fix, and then using "edit" on the 
> respective commit?
>   

This is what I do now.  Edit the commit, cherry-pick -n, and commit 
--amend.  But it's less pleasant than using the rebase --interactive 
interface.

[This is part of the workflow to prepare a patchset for submitting 
upstream; I don't edit commits on my master branch]

> That way you can even test the result easily, which you cannot do with 
> "squash".
>   

Usually these are trivial fixes, and have already been tested by being 
included in my main branch.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [PATCH] rebase -i: support single-letter abbreviations for the actions

[Johannes Schindelin]

Hi,

On Sat, 29 Sep 2007, Avi Kivity wrote:

> > > Can we make "amend" like squash, except that it keeps the first 
> > > commit's authorship instead of the second?  I often merge a commit 
> > > with some minor fix that comes later, and usually want to keep the 
> > > original author record.

Thinking about this again... Maybe it is a better semantics anyway? What 
do others think?

Ciao,
Dscho

Re: [PATCH] rebase -i: support single-letter abbreviations for the actions

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sat, 29 Sep 2007, Avi Kivity wrote:
>
>> > > Can we make "amend" like squash, except that it keeps the first 
>> > > commit's authorship instead of the second?  I often merge a commit 
>> > > with some minor fix that comes later, and usually want to keep the 
>> > > original author record.
>
> Thinking about this again... Maybe it is a better semantics anyway? What 
> do others think?

I never thought about whose commit the squashed ones become
before this thread, but making squash quack as if "commit
--amend" was done after running "cherry-pick -n" the second and
later ones feels like the most natural semantics to me.

[PATCH] rebase -i: squash should retain the authorship of the _first_ commit

[Johannes Schindelin]

It was determined on the mailing list, that it makes more sense for a 
"squash" to keep the author of the first commit as the author for the 
result of the squash.

Make it so.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Sat, 29 Sep 2007, Junio C Hamano wrote:

	> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
	> 
	> > On Sat, 29 Sep 2007, Avi Kivity wrote:
	> >
	> >> > > Can we make "amend" like squash, except that it keeps the 
	> >> > > first commit's authorship instead of the second?  I often 
	> >> > > merge a commit with some minor fix that comes later, and 
	> >> > > usually want to keep the original author record.
	> >
	> > Thinking about this again... Maybe it is a better semantics 
	> > anyway? What do others think?
	> 
	> I never thought about whose commit the squashed ones become
	> before this thread, but making squash quack as if "commit
	> --amend" was done after running "cherry-pick -n" the second and
	> later ones feels like the most natural semantics to me.

	Here you are.

 Documentation/git-rebase.txt  |    2 +-
 git-rebase--interactive.sh    |    2 +-
 t/t3404-rebase-interactive.sh |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 0858fa8..e8e7579 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -298,7 +298,7 @@ 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
 commits had different authors, it will attribute the squashed commit to
-the author of the last commit.
+the author of the first commit.
 
 In both cases, or when a "pick" does not succeed (because of merge
 errors), the loop will stop to let you fix things, and you can continue
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 7a5aaa5..050140d 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -276,9 +276,9 @@ do_next () {
 		esac
 
 		failed=f
+		author_script=$(get_author_ident_from_commit HEAD)
 		output git reset --soft HEAD^
 		pick_one -n $sha1 || failed=t
-		author_script=$(get_author_ident_from_commit $sha1)
 		echo "$author_script" > "$DOTEST"/author-script
 		case $failed in
 		f)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index f2214dd..1113904 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -180,7 +180,7 @@ test_expect_success 'squash' '
 '
 
 test_expect_success 'retain authorship when squashing' '
-	git show HEAD | grep "^Author: Nitfol"
+	git show HEAD | grep "^Author: Twerp Snog"
 '
 
 test_expect_success 'preserve merges with -p' '
-- 
1.5.3.2.1102.g9487