patchadditional help when editing during interactive rebase

I personally would have found this message useful the first time I used git rebase --interactive. YMMV.

Signed-off-by: William Morgan <wmorgan-git@masanjin.net>
---
 git-rebase--interactive.sh |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

William Morgan <wmorgan-git@masanjin.net> writes:

Aside from this message being inappropriate as a proposed commit log message, I think what the patch tries to achieve is a worthy UI improvement.

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?

Let the user know how to continue a rebase after amending a commit during a git rebase --interactive session.

Signed-off-by: William Morgan <wmorgan@masanjin.net>
---
 git-rebase--interactive.sh |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

Hi,

On Tue, 8 Jan 2008, Junio C Hamano wrote:

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

Note that "commit --amend" is _already_ called automatically if the index is dirty (but agrees with the working directory).

Then the user would be spared some additional typing, and the help could be changed to hint at "rebase --continue". It also would make things more consistent.

Ciao, Dscho

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

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.

Hi,

On Fri, 11 Jan 2008, Junio C Hamano wrote:

Yes, exactly.

If you want to split a commit into two or more, you will already have committed twice when you say "--continue", and all is fine.

However, if you do the first commit, and then only add the files for the second commit, the HEAD's commit name has changed! And so, rebase can pick up on that, and avoid the --amend.

IOW something like below. However, this patch does not yet make "rebase -i" call "commit --amend" automatically when both the index and HEAD are unchanged.

-- snipsnap -- [PATCH] rebase -i: only ever commit --amend when HEAD is untouched

When a commit is marked to edit, and the index is dirty when "rebase --continue" is called, that state will be committed with the "--amend" option.

However, this is wrong when the user wanted to split the commit.

Luckily, we can pick up on that, by recording the HEAD's name in the file "amend", and only --amend when no commit was made in the interim.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 git-rebase--interactive.sh |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)