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

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

"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(-)