Re: [GSoC update] Sequencer for inclusion

[Jeff King <peff@peff.net>]

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