Re: [RFC PATCH 00/11] Sequencer Foundations

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi Christian,

Christian Couder writes:
> On Monday 11 April 2011 06:49:05 Ramkumar Ramachandra wrote:
> > > > 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.

> > 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