Re: [RFC PATCH 00/11] Sequencer Foundations

Hi Christian,

Christian Couder writes:

On Monday 11 April 2011 06:49:05 Ramkumar Ramachandra wrote:

quoted

quoted

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

I wouldn't like either, but I would like it even less if it was like this:

pick 83a4fe9 # -m 1 -s -r 
revert 3a6fe42 # -n 
pick dacfe41 # -x --ff 
pick b31d4e2 # -s recursive -Xpatience 

I mean that of course people should not use too many options for no good 
reason, but if they do need to use some options, it's better if they are shown 
like in a shell, as they will be more familiar with them this way.

There is no point of making options look different to prevent people from 
abusing them.

You're right -- no point obscuring things.  I can't help thinking that
there must be a more elegant representation.  I'll think about it for
a while, and try to come up with something.

quoted

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.

I don't see the point of this global set. And if the sequencer knows nothing 
about it, the user may not know about it too and so may not understand how 
things work.

Hm.  I originally wanted this so that each commit in the instruction
sheet isn't polluted with the same command-line options, but this
doesn't seem to be a good solution.

-- Ram