Re: [PATCH 2/2] rebase -i: use some kind of config file to save author information

[Junio C Hamano <gitster@pobox.com>]

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

> On Sat, 20 Jun 2009, Christian Couder wrote:
>
>> This is better than saving in a shell script, because it will make
>> it much easier to port "rebase -i" to C. This also removes some sed
>> regexps and some "eval"s.
>
> It will not make it easier to port "rebase -i" to C, as this is an 
> internal file.  The user is not supposed to touch it at all.  Only "rebase 
> -i".  So it would be very easy to just use a different on-disk format when 
> turning "rebase -i" into a builtin.

"This is an internal file" is just a declaration you are making, and the
file is observable by anybody after "rebase -i" relinquishes the control
to let the user sort out the mess.  The users do not have any obligation
to honor your declaration, and strictly speaking it is a regression to
change the file format.

For example, when I realize I misspelt somebody's name (perhaps the
mailpath between the sender and me mishandled the encoding headers), I
could edit .git/rebase-merge/author-script and say "git rebase --continue"
to let auto-amend to kick in, which would use the fixed author name from
the file.

	Side note.  The current "rebase --continue" behaviour is somewhat
	inconsistent; if "edit" does not do anything to the tree, nor the
	user runs "git commit --amend', the commit is untouched, but if
	the user updates the index and says --continue without amending,
	the authorship is not taken from the auto-amended commit but is
	taken from the author-script file.  Perhaps something along the
	line of untested patch attached at the end would remedy this a
	bit? 

Having said that, if we were to change the way rebase-i leaves its state
behind so that it can pick up from where it left off, I prefer Christian's
later suggestion to leave the object name of the commit that is being
rebased in the file.  Sure, it makes it harder to lie about the authorship,
but my previous example was purely "I _could_ do this" and not "I rely on
being able to do this".

But I have this nagging feeling that we may be able to get rid of even the
"current commit".

-- >8 --

rebase -i: AUTHOR_{NAME,EMAIL,DATE} are already available in HEAD; use it.

This only changes the codepath of "rebase -i --continue" that auto-amends
the HEAD commit with the change user made but forgot to "commit --amend".

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

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f96d887..b8608be 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -522,8 +522,7 @@ first and then run 'git rebase --continue' again."
 				git reset --soft HEAD^ ||
 				die "Cannot rewind the HEAD"
 			fi
-			export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
-			git commit --no-verify -F "$DOTEST"/message -e || {
+			git commit --no-verify -c HEAD || {
 				test -n "$amend" && git reset --soft $amend
 				die "Could not commit staged changes."
 			}