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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Jun 22, 2009, 04:50 UTC
Message-ID: <200906220650.27685.chriscool@tuxfamily.org>
In-Reply-To: <7v1vpdqiv2.fsf@alter.siamese.dyndns.org>

On Monday 22 June 2009, Junio C Hamano wrote:

Show 10 quoted lines

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

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.

Show 20 quoted lines

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

Show 6 quoted lines

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