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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2008, 00:33 UTC
Message-ID: <7viqt6cg4t.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1220906569-26878-2-git-send-email-dpotapov@gmail.com>

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

Show 10 quoted lines

> 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.

Show 9 quoted lines

>  		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?