On Monday 22 June 2009, Johannes Schindelin wrote: > Hi, > > On Sun, 21 Jun 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. > > > > "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. > > It is an observation I am making. Sure, the file is observable by the > user. But it is hidden deep inside .git/ and users who change things > inside .git/ (with the exception of config) are asking for trouble. > > I really do not see the point of changing the file format _before_ > turning rebase -i into C. > > Oh, and I do not see the point of turning rebase -i into C before finally > polishing sequencer so it can go into git.git's master. The problem with this is that it will take a lot of time to implement the features that have been added to rebase -i since the sequencer stalled, then to polish it, and to get it reviewed and so on, and during that time other features or changes may be implemented by other people. So I prefer to use code from the current sequencer (at http://repo.or.cz/w/git/sbeyer.git) to start porting step by step rebase -i to C. Regards, 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