Re: [PATCH] additional help when editing during interactive rebase

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 11, 2008, 08:42 UTC
Message-ID: <7vprw83g8z.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LSU.1.00.0801091120150.31053@racer.site>

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

Show 12 quoted lines

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