On Tue, Jul 12, 2011 at 12:11:44PM +0530, Ramkumar Ramachandra wrote:
> > 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.
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. :)
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).
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.
-Peff
--
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