Re: [PATCH 2/2] git-rebase--interactive: auto amend only edited commit

[Junio C Hamano <gitster@pobox.com>]

I may not be reading your patch correctly; I am confused by what you are
trying to do.

> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 5b2b1e5..84721c9 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -284,7 +284,7 @@ do_next () {
>  		pick_one $sha1 ||
>  			die_with_patch $sha1 "Could not apply $sha1... $rest"
>  		make_patch $sha1
> -		: > "$DOTEST"/amend
> +		echo $sha1 > "$DOTEST"/amend

You record the $sha1 from the TODO file.  If you are editing the first one
in the insn sequence, that is also the same as HEAD (i.e. the commit you
are telling the user to modify with "commit --amend").  If you already
have edited earlier ones, it is not the value of HEAD at this point.

>  		warn "Stopped at $sha1... $rest"
>  		warn "You can amend the commit now, with"
>  		warn
> @@ -430,6 +430,8 @@ do
>  			if test -f "$DOTEST"/amend
>  			then
>  				amend=$(git rev-parse --verify HEAD)
> +				test "$amend" = $(cat "$DOTEST"/amend) ||
> +				die "You have uncommitted changes"

And then you complain if HEAD, after running "commit --amend", is
not the value you recorded above.

>  				git reset --soft HEAD^ ||
>  				die "Cannot rewind the HEAD"
>  			fi

If the first commit was marked as "edit", then the value you recorded in
"$DOTEST/amend" was the HEAD, the commit the user was told to modify with
"commit --amend".  $DOTEST/amend being the same as HEAD here would be a
sign that the user staged changes but hasn't done "commit --amend".

But if we think about the second and subsequent commits that are marked as
"edit" in TODO file, the value recorded in "$DOTEST/amend" would not be
the value of HEAD at this point, and whether "commit --amend" has been run
or not, the value of HEAD is very likely to be different from that value
(unless the user said "reset --hard $that_one").  Wouldn't this test
almost always complain for them?

Perhaps you wanted to record the value of the HEAD in the first hunk?

How would this change interact with the workflow of splitting existing
commits, described at the end of git-rebase documentation?