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.
> +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
--
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