Re: [PATCH/RFC] Hacky version of a glob() driven config include
- From
Jeff King <peff@peff.net>
- Date
- May 8, 2010, 05:06 UTC
- Message-ID
- <20100508050632.GE14998@coredump.intra.peff.net>
- In-Reply-To
- <1273180440-8641-1-git-send-email-avarab@gmail.com>
On Thu, May 06, 2010 at 09:14:00PM +0000, Ævar Arnfjörð Bjarmason wrote:
> This is not ready for inclusion in anything. Commiting for RFC on > whether this way of doing it is sane in theory.
I think the goal of having globbing include files is reasonable.
> * It relies on the GNU GLOB_TILDE extension with no
> alternative. That can be done by calling getenv("HOME") and
> s/~/$home/.We already have expand_user_path which handles ~ properly (it is used for the values of some config entries). You could then glob the result.
Show 6 quoted lines
> +cat > .git/config << EOF > +[some] > + variable = blah > +[voodoo] > + include = .git/more_config_* > +EOF
My eyes! The goggles do nothing!
That syntax is horrid. Wouldn't it be much simpler to introduce some top-level syntax for "include this file here", with some very simple semantics:
- the included file starts with no section. It should have its own
section header. - after returning from the included file, we are in no section. You
need a new section header.Yes, there are some complex tricks those semantics won't allow, but they are simple to read and understand, simple to use, and simple to implement.
And really, what is the point in supporting crap like:
$ cat .gitconfig [diff] #include foo
$ cat foo rename = true
-Peff