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

quoted text
> Hi,
>
> On Tue, 8 Jan 2008, Junio C Hamano wrote:
>
>> I would have removed those empty lines around the instruction if I were 
>> patching this, though.  Losing 5 lines out of 25-line terminal was 
>> marginally Ok.  Losing 9 lines 4 lines too many and is unacceptable.
>> 
>> Thoughts?
>
> I wonder if it would not make even more sense to record the current HEAD 
> name, and call "commit --amend" if it is the same upon "--continue".

My understanding of the original issue is that "git-rebase -i"
stops at 'edit' and gives the user a chance to muck with the
commit, saying "do whatever you want now and then record the
result with git commit --amend".  The user can follow that but
then needs to say "git rebase --continue" after that.  The insn
does not talk about it, so after running "git commit --amend" as
told, a clueless user is left wondering "huh, and then now
what?".

Do you mean you would instead suggest "git rebase --continue" in
the insn, and make the workflow like this:

	$ git rebase -i ...
        Now do whatever you want and say "rebase --continue"
	$ edit foo.c
        $ git add foo.c
        $ git rebase --continue

and have "rebase --continue" to continue with the modified
contents recorded in the index, invoking "git commit --amend",
but doing so only if the user hasn't run "git commit" with or
without --amend yet?

It feels like a better automation than what we currently have,
but I somewhat worry how that would change the user experience
for using 'edit' to split a commit into two or more.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html