Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
