From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Tue, 12 Jul 2011 06:41:44 GMT
Subject: Re: [GSoC update] Sequencer for inclusion
Message-ID: <CALkWK0n41LZ8-ZU2M1oD_ddJ2g2A47MxuO8w+5Ew6Php8gvF+g@mail.gmail.com>
In-Reply-To: <20110711221419.GE30155@sigill.intra.peff.net>

Hi Jeff, Junio, Jonathan, and Miles,

Jeff King writes:
> On Mon, Jul 11, 2011 at 01:07:20PM -0700, Junio C Hamano wrote:
>> > To be precise, the format used includes
>> >
>> >     strategy-option = patience | renormalize
>> >
>> > to represent the effect of "-Xpatience -Xrenormalize".  My only worry
>> > about that is that the "|" can sound like "or", which would seem
>> > strange to a user that does not necessarily develop software (so is
>> > not thinking about bitfields).  The format used in config files puts
>> >
>> >     strategy-option = patience
>> >     strategy-option = renormalize
>> >
>> > as separate lines.
>>
>> A very good point again. I do not think anywhere in our codebase we use
>> "|" as a separator for state files (either used for internal or exposed to
>> the end user), and we probably would want to be consistent across
>> commands.
>
> I had the same feeling about the "|". I'm a little confused about what
> these options are good for, though.

Miles Bader writes:
> How about using "+" instead of "|"...?
>
> I think that would make sense both for bitfield-thinking and
> non-bitfield-thinking readers ... :]

Frankly, I don't like the idea of separate lines like "key = value1"
and "key = value 2" -- even a generic *nix configuration file parser
would break here.  Yes, I know that we don't use "|" anywhere else; we
don't persist options anywhere else either, so I was trying to be
inventive :p

I didn't realize "|" would confuse users -- if that's the case, should
we use a different separator like Miles' "+" suggestion?

Jeff King writes:
> Is it purely about saving some persistent data between runs, and nobody
> else is going to look at it? In that case, I don't think it matters what
> the format is. Use some unambiguous encoding that we already have
> available (like sq_quote_argv and sq_dequote_argv), and write as little
> code as possible.
>
> Or is it something that, like the information in .git/rebase-apply,
> people might want to read or tweak? In that case, might it make sense to
> follow that lead and split things into one file per item? That keeps the
> parsing burden extremely low for things like shell scripts (or shell
> users) who might want to read or tweak.

Yes, it's a little like the information in .git/rebase-apply.  We
should give the user the ability to tweak it by hand: the result from
sq_quote_argv and sq_dequote_argv would look very ugly.  Hm, I don't
like the one-file-per-command-line-option approach because: we might
only have a few options now, but when the sequencer is built to
support many actions and options, the directory will be polluted with
lots of files.  I was thinking more along the lines of something that
can be parsed using gitconfig.

Thanks.

-- Ram