Re: [RFC PATCH] An option parser for the sequencer

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

Christian Couder writes:
> On Saturday 09 July 2011 17:41:57 Ramkumar Ramachandra wrote:
>> I've decided not to support arbitrary command-line options in the
>> instruction sheet.
>
> It may be a good decision, but could you explain why? You could say for
> example that the series would be already an improvement over what we have if
> we don't parse arbitrary command line options.

Here's an elaborate justification:
1. Parsing arbitrary command-line options means that we'd have to
support two versions of every command: the short version and the long
version.  As a result, two configuration files may be functionally
identical, but not really identical because one uses short versions
and the other uses long versions.   This is ugly/ inelegant.
2. The format can be quite loose: for example "--ff -s" is equivalent
to "---ff   '-s'".  We'll either have to go through the trouble to
sanitize everything at the time of persistence, or go through that
trouble while reading.  We can't entirely avoid this ugliness.
3. Where do we stop? Is something like "for i in "moo foo"; do $i;
done;" allowed?  How do we draw clear boundaries?
4. Most importantly, we're NOT building a fast git shell.  There's no
point implementing a reduced shell parser inside Git -- there are many
existing shells we can leverage, if that's what we want.

Besides, I can't think of a good enough usecase for per-instruction
command-line options right now.  How often would someone want to
cherry-pick 10 commits, but signoff on 3 of them somewhere in the
middle?  Not to say that we should not support per-instruction
command-line options: just that we can wait until someone figures out
a great usecase + a good implementation.  It's not critical.

Let's go back to the problem at hand -- what are we trying to do?  The
problem is to get cherry-pick/ revert to support '--continue', and
'--reset' as soon as possible and get it merged.  So, all we need is
one set of options to persist along with the head and todo.  A simple
"key = value" format is both simple and elegant; so we can go ahead
with it, and see how things play out later.  Since none of this is
exposed to the end-user, I don't see us locking ourselves into
short-sighted design at any rate.

>> A typical instruction sheet will looks like this
>> (inspired heavily by the rebase -i instruction sheet format):
>
>> pick 3b36854 t: add tests for cloning remotes with detached HEAD
>> pick 61adfd3 consider only branches in guess_remote_head
>> pick 8537f0e submodule add: test failure when url is not configured in
>> superproject pick 4d68932 submodule add: allow relative repository path
>> even when no url is set pick f22a17e submodule add: clean up duplicated
>> code
>> pick 59a5775 make copy_ref globally available
>> pick c1921c1 clone: always fetch remote HEAD
>
> Would it be easy to change the format to support arbitrary command line
> options if we want to do it afterwards, especially after the end of the GSoC?

Why not?  We aren't explicitly showing this to the end-user yet, so I
see no problem with changing it.  We should worry about that only when
we develop a feature like "cherry-pick -i".

>> For persisting one set of options for every "git cherry-pick"/ "git
>> revert" invocation, I've decided to use a simple "key = value" format
>> and put it in .git/sequencer/opts (to sit beside .git/sequencer/head
>> and .git/sequencer/todo).  For strategy-option, I thought it would be
>> cute to separate the various options using ' | '.  So, it'll look
>> something like this in the end:
>>
>> signoff = true
>> mainline = 1
>> strategy-option = recursive | ours
>
> Is it the same format as the .git/config file format? Would it be possible to
> reuse some config parsing/writing code?

Yes; I'm currently working on it.  I just wanted to show a simple PoC,
but I will try to avoid introducing new parsers and the bugs that come
along with it.

Thanks.

-- Ram