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

On Monday 22 June 2009, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Sat, 20 Jun 2009, Christian Couder wrote:

quoted

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.

I'd rather port "rebase -i" to C step by step like I started 
porting "bisect". So changing the format to something easier to deal with 
in C makes it easier to port.

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

Interesting. I will try it.

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

I just sent a v3 where the commit sha1 is saved in the file, so you can 
choose between v2 and v3 what behavior you prefer.

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

I will have a look at that.

Thanks,
Christian.