On Monday 22 June 2009, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > "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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html