[PATCH 2/2] rebase -i: fix post-rewrite hook with failed exec command

[PATCH 2/2] rebase -i: fix post-rewrite hook with failed exec command

[Matthieu Moy]

[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]

Usually, when 'git rebase' stops before completing the rebase, it is to
give the user an opportunity to edit a commit (e.g. with the 'edit'
command). In such cases, 'git rebase' leaves the sha1 of the commit being
rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase
--continue' will call the post-rewrite hook with this sha1 as <old-sha1>
argument to the post-rewrite hook.

The case of 'git rebase' stopping because of a failed 'exec' command is
different: it gives the opportunity to the user to examine or fix the
failure, but does not stop saying "here's a commit to edit, use
--continue when you're done". So, there's no reason to call the
post-rewrite hook for 'exec' commands. If the user did rewrite the
commit, it would be with 'git commit --amend' which already called the
post-rewrite hook.

Fix the behavior to leave no stopped-sha file in case of failed exec
command, and teach 'git rebase --continue' to skip record_in_rewritten if
no stopped-sha file is found.
---
 git-rebase--interactive.sh   | 10 +++++-----
 t/t5407-post-rewrite-hook.sh |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 08e5d86..1c321e4 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -486,7 +486,7 @@ do_pick () {
 }
 
 do_next () {
-	rm -f "$msg" "$author_script" "$amend" || exit
+	rm -f "$msg" "$author_script" "$amend" "$state_dir"/stopped-sha || exit
 	read -r command sha1 rest < "$todo"
 	case "$command" in
 	"$comment_char"*|''|noop)
@@ -576,9 +576,6 @@ do_next () {
 		read -r command rest < "$todo"
 		mark_action_done
 		printf 'Executing: %s\n' "$rest"
-		# "exec" command doesn't take a sha1 in the todo-list.
-		# => can't just use $sha1 here.
-		git rev-parse --verify HEAD > "$state_dir"/stopped-sha
 		${SHELL:-@SHELL_PATH@} -c "$rest" # Actual execution
 		status=$?
 		# Run in subshell because require_clean_work_tree can die.
@@ -874,7 +871,10 @@ first and then run 'git rebase --continue' again."
 		fi
 	fi
 
-	record_in_rewritten "$(cat "$state_dir"/stopped-sha)"
+	if test -r "$state_dir"/stopped-sha
+	then
+		record_in_rewritten "$(cat "$state_dir"/stopped-sha)"
+	fi
 
 	require_clean_work_tree "rebase"
 	do_rest
diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5407-post-rewrite-hook.sh
index 53a4062..06ffad6 100755
--- a/t/t5407-post-rewrite-hook.sh
+++ b/t/t5407-post-rewrite-hook.sh
@@ -212,7 +212,7 @@ EOF
 	verify_hook_input
 '
 
-test_expect_failure 'git rebase -i (exec)' '
+test_expect_success 'git rebase -i (exec)' '
 	git reset --hard D &&
 	clear_hook_input &&
 	FAKE_LINES="edit 1 exec_false 2" git rebase -i B &&

---
https://github.com/git/git/pull/138

[PATCH 1/2] rebase -i: demonstrate incorrect behavior of post-rewrite

[Matthieu Moy]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

The 'exec' command is sending the current commit to stopped-sha, which is
supposed to contain the original commit (before rebase). As a result, if
an 'exec' command fails, the next 'git rebase --continue' will send the
current commit as <old-sha1> to the post-rewrite hook.

The test currently fails with :

--- expected.data       2015-05-21 17:55:29.000000000 +0000
+++ [...]post-rewrite.data      2015-05-21 17:55:29.000000000 +0000
@@ -1,2 +1,3 @@
 2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab
+488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab
 babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507
---
 t/t5407-post-rewrite-hook.sh | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5407-post-rewrite-hook.sh
index ea2e0d4..53a4062 100755
--- a/t/t5407-post-rewrite-hook.sh
+++ b/t/t5407-post-rewrite-hook.sh
@@ -212,4 +212,21 @@ EOF
 	verify_hook_input
 '
 
+test_expect_failure 'git rebase -i (exec)' '
+	git reset --hard D &&
+	clear_hook_input &&
+	FAKE_LINES="edit 1 exec_false 2" git rebase -i B &&
+	echo something >bar &&
+	git add bar &&
+	# Fails because of exec false
+	test_must_fail git rebase --continue &&
+	git rebase --continue &&
+	echo rebase >expected.args &&
+	cat >expected.data <<EOF &&
+$(git rev-parse C) $(git rev-parse HEAD^)
+$(git rev-parse D) $(git rev-parse HEAD)
+EOF
+	verify_hook_input
+'
+
 test_done


---
https://github.com/git/git/pull/138

Re: [PATCH 1/2] rebase -i: demonstrate incorrect behavior of post-rewrite

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> The 'exec' command is sending the current commit to stopped-sha, which is
> supposed to contain the original commit (before rebase). As a result, if
> an 'exec' command fails, the next 'git rebase --continue' will send the
> current commit as <old-sha1> to the post-rewrite hook.
>
> The test currently fails with :
>
> --- expected.data       2015-05-21 17:55:29.000000000 +0000
> +++ [...]post-rewrite.data      2015-05-21 17:55:29.000000000 +0000
> @@ -1,2 +1,3 @@
>  2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab
> +488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab
>  babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507

Indent displayed material like the above a bit, please.
And please sign-off your patches.

> ---
>  t/t5407-post-rewrite-hook.sh | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5407-post-rewrite-hook.sh
> index ea2e0d4..53a4062 100755
> --- a/t/t5407-post-rewrite-hook.sh
> +++ b/t/t5407-post-rewrite-hook.sh
> @@ -212,4 +212,21 @@ EOF
>  	verify_hook_input
>  '
>  
> +test_expect_failure 'git rebase -i (exec)' '
> +	git reset --hard D &&
> +	clear_hook_input &&
> +	FAKE_LINES="edit 1 exec_false 2" git rebase -i B &&
> +	echo something >bar &&
> +	git add bar &&
> +	# Fails because of exec false
> +	test_must_fail git rebase --continue &&
> +	git rebase --continue &&
> +	echo rebase >expected.args &&
> +	cat >expected.data <<EOF &&
> +$(git rev-parse C) $(git rev-parse HEAD^)
> +$(git rev-parse D) $(git rev-parse HEAD)
> +EOF

By using a dash to start the here-document like this:

	cat >expect <<-\EOF &&
	$(git rev-parse C) $(git rev-parse HEAD^)
        ...
        EOF

you can tab-indent the contents and the end marker at the same level
to make it easier to read.

> +	verify_hook_input
> +'
> +
>  test_done
>
>
> ---
> https://github.com/git/git/pull/138

Re: [PATCH 1/2] rebase -i: demonstrate incorrect behavior of post-rewrite

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> The 'exec' command is sending the current commit to stopped-sha, which is
>> supposed to contain the original commit (before rebase). As a result, if
>> an 'exec' command fails, the next 'git rebase --continue' will send the
>> current commit as <old-sha1> to the post-rewrite hook.
>>
>> The test currently fails with :
>>
>> --- expected.data       2015-05-21 17:55:29.000000000 +0000
>> +++ [...]post-rewrite.data      2015-05-21 17:55:29.000000000 +0000
>> @@ -1,2 +1,3 @@
>>  2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab
>> +488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab
>>  babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507
>
> Indent displayed material like the above a bit, please.

OK, will do.

> And please sign-off your patches.

Ah, I was testing submitGit, and forgot that send-email was usually
doing this for me.

>> +	cat >expected.data <<EOF &&
>> +$(git rev-parse C) $(git rev-parse HEAD^)
>> +$(git rev-parse D) $(git rev-parse HEAD)
>> +EOF
>
> By using a dash to start the here-document like this:
>
> 	cat >expect <<-\EOF &&
> 	$(git rev-parse C) $(git rev-parse HEAD^)
>         ...
>         EOF
>
> you can tab-indent the contents and the end marker at the same level
> to make it easier to read.

I usually do that but I just mimicked the surrounding code for
consistency. If you really prefer the <<-\EOF I can resend with an
additional "modernize style" patch before and this one properly
formatted.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 1/2] rebase -i: demonstrate incorrect behavior of post-rewrite

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> +	cat >expected.data <<EOF &&
>> +$(git rev-parse C) $(git rev-parse HEAD^)
>> +$(git rev-parse D) $(git rev-parse HEAD)
>> +EOF
>
> By using a dash to start the here-document like this:
> ...

Sorry, I should have checked, as I know you know that <<-EOF thing.
Your patch is done this way to be consistent with existing ones.

I'll do a separate patch to clean them all up on top.

Thanks.

-- >8 --
Subject: [PATCH] t5407: use <<- to align the expected output

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t5407-post-rewrite-hook.sh | 80 ++++++++++++++++++++++----------------------
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/t/t5407-post-rewrite-hook.sh b/t/t5407-post-rewrite-hook.sh
index 06ffad6..7a48236 100755
--- a/t/t5407-post-rewrite-hook.sh
+++ b/t/t5407-post-rewrite-hook.sh
@@ -61,10 +61,10 @@ test_expect_success 'git rebase' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD^)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD^)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -77,9 +77,9 @@ test_expect_success 'git rebase --skip' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -89,9 +89,9 @@ test_expect_success 'git rebase --skip the last one' '
 	test_must_fail git rebase --onto D A &&
 	git rebase --skip &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse E) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse E) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -103,10 +103,10 @@ test_expect_success 'git rebase -m' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD^)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD^)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -119,9 +119,9 @@ test_expect_success 'git rebase -m --skip' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -148,10 +148,10 @@ test_expect_success 'git rebase -i (unchanged)' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD^)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD^)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -163,9 +163,9 @@ test_expect_success 'git rebase -i (skip)' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -177,10 +177,10 @@ test_expect_success 'git rebase -i (squash)' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -189,10 +189,10 @@ test_expect_success 'git rebase -i (fixup without conflict)' '
 	clear_hook_input &&
 	FAKE_LINES="1 fixup 2" git rebase -i B &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -205,10 +205,10 @@ test_expect_success 'git rebase -i (double edit)' '
 	git add foo &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD^)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD^)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
@@ -222,10 +222,10 @@ test_expect_success 'git rebase -i (exec)' '
 	test_must_fail git rebase --continue &&
 	git rebase --continue &&
 	echo rebase >expected.args &&
-	cat >expected.data <<EOF &&
-$(git rev-parse C) $(git rev-parse HEAD^)
-$(git rev-parse D) $(git rev-parse HEAD)
-EOF
+	cat >expected.data <<-EOF &&
+	$(git rev-parse C) $(git rev-parse HEAD^)
+	$(git rev-parse D) $(git rev-parse HEAD)
+	EOF
 	verify_hook_input
 '
 
-- 
2.4.1-439-gcfa393f

Re: [PATCH 1/2] rebase -i: demonstrate incorrect behavior of post-rewrite

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

>> And please sign-off your patches.
>
> Ah, I was testing submitGit, and forgot that send-email was usually
> doing this for me.

Ah, should have noticed from the message-id.

Roberto, isn't your threading of multi-patch series busted?

Why is 1/2 a follow-up to 2/2?  Do you have a time-machine ;-)?

Re: [PATCH 1/2] rebase -i: demonstrate incorrect behavior of post-rewrite

[Roberto Tyley]

On 22 May 2015 at 16:59, Junio C Hamano <gitster@pobox.com> wrote:
> Roberto, isn't your threading of multi-patch series busted?
>
> Why is 1/2 a follow-up to 2/2?  Do you have a time-machine ;-)?

Oh, embarrassing, I better destroy the time-machine:

https://github.com/rtyley/submitgit/pull/5

This was due to me not realising that the GitHub API returns commit lists for
PRs in reverse-chronological order... thanks for pointing that out!