From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Wed, 13 Jul 2011 09:41:54 GMT
Subject: Re: [GSoC update] Sequencer for inclusion
Message-ID: <CALkWK0=EDZ9E1qYg=bEt2h3jmUUvERoiR1TpkUupRO2XrYyt9A@mail.gmail.com>
In-Reply-To: <20110712064706.GA13375@sigill.intra.peff.net>

Hi Jeff,

Jeff King writes:
> On Tue, Jul 12, 2011 at 12:11:44PM +0530, Ramkumar Ramachandra wrote:
>> 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.
>
> I don't consider having lots of files there "pollution", but rather "a
> well-used key/value store". But I suppose it is in the eye of the
> beholder. :)

Ha, true.  After all .git/objects/ is "polluted" with lots of files :p
A couple of questions arise:
1. Would opening, writing, closing many files not put too much strain
on I/O, and hence affect performance significantly?
2. Will two options from different instructions (when we extend the
instruction sheet to accommodate them) have the same name, but
different effects?  Having a gitconfig-like configuration file doesn't
solve this problem either, so it's not a "configfile versus key-value
store" question.

> Using git-config is maybe a little more self-documenting than something
> like "sq_quote_argv". And probably not much more code (maybe even less,
> since it can handle the file update for you).

Yeah :)

> I recently used the config code to write out a non-standard config file.
> My two complaints were:
>
>  1. You can't queue up a bunch of changes and then write the file once.
>     Every time you call git_config_set, it rewrites the whole file.
>
>  2. There's no way to write to a nonstandard file short of the horribly
>     hack-ish:
>
>       const char *saved = config_exclusive_filename;
>       config_exclusive_filename = "foo.conf";
>       git_config_set(...);
>       config_exclusive_filename = saved;
>
> Point (2) is pretty easy to fix. But point (1) might be a bit more
> involved. I haven't really looked yet.

Thanks for pointing these out.  Yes, I'm aware of these issues, and
it's part of the reason I implemented my own parser.  It'll take some
time to refactor config.c so that it's usable by others in a sane
manner, no?  What do you suggest I do until then?  Can I try to get my
custom parser merged (and replaced by a more generic configparser when
it's ready), or should I throw away my parser and go with the
key-value store?

Just to clarify, here's an example to illustrate what I understand
when you say key-value store (please correct me if I got the idea
wrong):
.git/sequencer/opts/ will have files like:
$ cat ff
true
$ cat record-origin
true
$ cat mainline
1
$ cat strategy
ours
$ cat strategy-option
patience + renormalize

-- Ram