Re: [RFC PATCH 00/11] Sequencer Foundations

Hi Christian,

Christian Couder writes:

On Sunday 10 April 2011 17:11:46 Ramkumar Ramachandra wrote:

quoted

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.

quoted

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.

quoted

[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