Hi, On Tue, 23 Jun 2009, Christian Couder wrote: > On Monday 22 June 2009, Johannes Schindelin wrote: > > > 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. I think that the best way to go forward would be to have something like fetch--tool, i.e. a builtin helper that successively takes more and more functionality into C. IMHO a first sensible step would be to implement the commands ("pick", "squash", "edit") in such a helper, and call them from do_next(). That should take care of the most difficult part, getting the transition started. But I had the impression that the sequencer started out almost like this, but then it also wanted to implement the do_next() and everything. Ciao, Dscho -- 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