Hi Christian, Christian Couder writes: > On Sunday 10 April 2011 17:11:46 Ramkumar Ramachandra wrote: > > Hi, > > > > I've started working on building a sequencer for Git. > > So you are starting the GSoC early! Great! > When (or before) it really starts, just make sure you put your work on a > public Git repository and you send status updates regularly (weekly if > possible). Ofcourse. I've already discussed many of these issues last year [1]. The work corresponding to this particular series can be found in the 'sequencer' branch on my GitHub fork [2]. Since the results haven't been announced, and the coding period hasn't begun, this work should be treated like "normal work" -- I just wrote it this weekend. > > 3. From the format of the TODO and DONE files, one more thing should > > be clear- I'm trying to stick to a slight variation of the 'rebase -i' > > format. This part will go into the sequencer. Then I'll use a > > cherry-pick specific file to keep the command-line options. Yes, I'm > > trying to work on Daniel's idea [3] from the very start. Is this a > > good idea? > > I think that the TODO and DONE file format will need at one point to include > options and it is simpler if this change is done early. Using a cherry-pick > specific file to keep the options is not very generic for a sequencer that could > be used for many things. > > For example, as we have rebase --interactive, we will probably want to have > cherry-pick --interactive, and when editing the TODO file we might want to use > different cherry-pick options when picking different commits. Point noted -- I shouldn't narrow down the various things I can do with a single commit early on and lock us into a more restrictive design. However, I'm not in favor of making it too generic; I certainly wouldn't like to edit an instruction sheet that looks like this: cherry-pick -m 1 -s -r 83a4fe9 revert -n 3a6fe42 cherry-pick -x --ff dacfe41 cherry-pick -s recursive -Xpatience b31d4e2 It'll become impossible to tell which options are disallowed over what else, and it'll become a nightmare to debug when something goes wrong. My idea is that we add commit-specific options in an optional backward-compatible manner later: pick 83a4fe9 revert 3a6fe42 # -n pick dacfe41 # -s pick b31d4e2 That way, there'll be two sets of options: 1. One "global" set of command-line switches that applies to all the commits, which will be written to a command-specific location. The sequencer itself knows nothing about this. 2. Optional commit-specific stuff that's passed in the form of a (modified) commit_list to the sequencer API to write to the todo/ done files. Do you like this idea? > This would also make the different cherry-pick options available when using > rebase --interactive once it uses the sequencer. > > > [1]: > > http://thread.gmane.org/gmane.comp.version-control.git/170758/focus=170908 > > [2]: http://thread.gmane.org/gmane.comp.version-control.git/162183 [3]: > > http://thread.gmane.org/gmane.comp.version-control.git/170758/focus=170834 > > [3] is missing here. Your email client is perhaps wrapping too aggressively? It's fine in my original email [3]. -- Ram [1]: http://thread.gmane.org/gmane.comp.version-control.git/142623/focus=142821 [2]: https://github.com/artagnon/git [2]: http://article.gmane.org/gmane.comp.version-control.git/171255 -- 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