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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html