{"thread":{"id":"23291","subject":"Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","startedAt":"2010-04-01T21:20:46Z","lastAt":"2010-05-08T09:03:15Z","messageCount":21,"participants":["Ævar Arnfjörð Bjarmason","Heiko Voigt","Peter Krefting","Eli Barzilay","Jakub Narebski","Bert Wesarg","Jacob Helwig","Ping Yin","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"138361","messageId":"z2s51dd1af81004011420ka5d3a800kf6b3e4591527fc12@mail.gmail.com","threadId":"23291","inReplyTo":null,"subject":"Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-01T21:20:46Z","receivedAt":"2010-04-01T21:20:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"I've patched Git to read ~/.gitconfig.d/* and /etc/gitconfig.d/* in\naddition to reading ~/.gitconfig and /etc/gitconfig where it would\nnormally do so. the gitconfig.d/* files are read in numeric sort order\nas is the custom with such files and read after the main .gitconfig\nfile so they override it.\n\nThis is very useful for me because I maintain my .gitconfig in a\npublic git repository but I don't want anyone to know my github.token.\nBecause of that I have to do a little song & dance every time I commit\nto the file (if the token is part of the diff) or pull to the file (to\nnot encounter a merge conflict).\n\nThis would also facilitate neat stuff like easily using bits of other\npeople's gitconfig libraries by cloning their repository somewhere and\nsymlinking their .gitconfig to ~/.gitconfig.d/99-some-library.\n\nI'm not attaching my patch because it would be inhumane to subject\nanyone to it in its current state. However, I'd like to ask if there's\nany interest in getting a proper & documented patch for this. If so I\ncan submit a proper patch, if not I can just continue to patch my Git\nbuild with my hack.\n\nApologies if this has been brought up before. I tried to search for\nprior art but \".gitconfig.d\" makes for a really bad search query in\nall the search engines I could find that index this list.\n"},{"id":"138365","messageId":"20100401220359.GA37149@book.hvoigt.net","threadId":"23291","inReplyTo":"z2s51dd1af81004011420ka5d3a800kf6b3e4591527fc12@mail.gmail.com","subject":"Re: Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2010-04-01T22:03:59Z","receivedAt":"2010-04-01T22:03:59Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Apr 01, 2010 at 09:20:46PM +0000, Ævar Arnfjörð Bjarmason wrote:\n> I've patched Git to read ~/.gitconfig.d/* and /etc/gitconfig.d/* in\n> addition to reading ~/.gitconfig and /etc/gitconfig where it would\n> normally do so. the gitconfig.d/* files are read in numeric sort order\n> as is the custom with such files and read after the main .gitconfig\n> file so they override it.\n\nI like the idea and it would be great if we could extend it to hooks as\nwell. I know that you can implement hooks that themself read such a\nstructure but its not that neat as git handling this itself.\n\nThat would be a great way to distribute configurations to users as you\ncould say: \"Put this file into your gitconfig.d/hooks.d folder and you\nget this and that kind of configuration.\"\n\ncheers Heiko\n"},{"id":"138526","messageId":"alpine.DEB.2.00.1004040922500.30612@perkele.intern.softwolves.pp.se","threadId":"23291","inReplyTo":"z2s51dd1af81004011420ka5d3a800kf6b3e4591527fc12@mail.gmail.com","subject":"Re: Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-04-04T07:24:15Z","receivedAt":"2010-04-04T07:24:15Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Ævar Arnfjörð Bjarmason:\n\n> However, I'd like to ask if there's any interest in getting a proper & \n> documented patch for this. If so I can submit a proper patch, if not I can \n> just continue to patch my Git build with my hack.\n\nI'd be interested. I also maintain my .gitconfig in a version control system \n(sadly not Git itself, because I don't have it available on all hosts I have \nthe files checked out on), and would like to be able to store the \nhost-specific settings out of the way (specifically for me that is \nuser.email).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"138527","messageId":"19384.18141.329087.730618@winooski.ccs.neu.edu","threadId":"23291","inReplyTo":"alpine.DEB.2.00.1004040922500.30612@perkele.intern.softwolves.pp.se","subject":"Re: Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-04-04T07:59:25Z","receivedAt":"2010-04-04T07:59:25Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Apr  4, Peter Krefting wrote:\n> Ævar Arnfjörð Bjarmason:\n> \n> > However, I'd like to ask if there's any interest in getting a proper & \n> > documented patch for this. If so I can submit a proper patch, if not I can \n> > just continue to patch my Git build with my hack.\n> \n> I'd be interested. I also maintain my .gitconfig in a version control system \n> (sadly not Git itself, because I don't have it available on all hosts I have \n> the files checked out on), and would like to be able to store the \n> host-specific settings out of the way (specifically for me that is \n> user.email).\n\nIsn't it better to have a way to include files instead?\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"138722","messageId":"u2i51dd1af81004060115t5f837840z5adcf83622fa8882@mail.gmail.com","threadId":"23291","inReplyTo":"19384.17579.205005.86711@winooski.ccs.neu.edu","subject":"Re: Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-06T08:15:35Z","receivedAt":"2010-04-06T08:15:35Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Apr 4, 2010 at 07:50, Eli Barzilay <eli@barzilay.org> wrote:\n> Isn't it better to have a way to include files instead?\n\nProbably yes. Programs like Apache HTTPD, rsyslog and others just use\n${foo}conf.d by convention by supporting config inclusion.\n\nWhat would be the ideal config syntax for that? AFAICT git-config\ndoesn't (yet) support top-level keys so maybe this:\n\n    [INCLUDE]\n        path = ~/.gitconfig.d/*\n\nOr if top-level support was added:\n\n    INCLUDE = ~/.gitconfig.d/*\n"},{"id":"138727","messageId":"m36345hs4d.fsf@localhost.localdomain","threadId":"23291","inReplyTo":"u2i51dd1af81004060115t5f837840z5adcf83622fa8882@mail.gmail.com","subject":"Re: Is there interest in reading ~/.gitconfig.d/* and /etc/gitconfig.d/*?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-06T09:02:26Z","receivedAt":"2010-04-06T09:02:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> On Sun, Apr 4, 2010 at 07:50, Eli Barzilay <eli@barzilay.org> wrote:\n\n> > Isn't it better to have a way to include files instead?\n> \n> Probably yes. Programs like Apache HTTPD, rsyslog and others just use\n> ${foo}conf.d by convention by supporting config inclusion.\n> \n> What would be the ideal config syntax for that? AFAICT git-config\n> doesn't (yet) support top-level keys so maybe this:\n> \n>     [INCLUDE]\n>         path = ~/.gitconfig.d/*\n> \n> Or if top-level support was added:\n> \n>     INCLUDE = ~/.gitconfig.d/*\n\n<bikeshedding mode on>\n\nI think that it would be better to use\n\n        include ~/.gitconfig.d/*\n\n<bikeshedding mode off>\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"141089","messageId":"1273180440-8641-1-git-send-email-avarab@gmail.com","threadId":"23291","inReplyTo":"u2i51dd1af81004060115t5f837840z5adcf83622fa8882@mail.gmail.com","subject":"[PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-06T21:14:00Z","receivedAt":"2010-05-06T21:14:00Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"This is not ready for inclusion in anything. Commiting for RFC on\nwhether this way of doing it is sane in theory.\n\nKnown bugs:\n\n  * Breaks the model of being able to *set* config values. That\n    doesn't work for the included files. Maybe not a bug.\n\n  * Errors in the git_config_from_file() call in glob_include_config()\n    aren't passed upwards.\n\n  * It relies on the GNU GLOB_TILDE extension with no\n    alternative. That can be done by calling getenv(\"HOME\") and\n    s/~/$home/.\n\n  * The whole bit with saving/restoring global state for config\n    inclusion is evil, but then again so is the global state.\n\n  * We don't check for recursion. But Git gives up eventually after\n    after spewing a *lot* of duplicate entry errors. Not sure how to\n    do this sanely w/symlinks.\n\nNot-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\n> On Sun, Apr 4, 2010 at 07:50, Eli Barzilay <eli@barzilay.org> wrote:\n> > Isn't it better to have a way to include files instead?\n>\n> Probably yes. Programs like Apache HTTPD, rsyslog and others just use\n> ${foo}conf.d by convention by supporting config inclusion.\n\nHere's an evil implementation of this. I know the code is horrid &\nbuggy (see above). But is the general idea sane. I thought it would be\nbetter to submit this for comments before I went further with it.\n\n config.c               |   55 +++++++++++++++++++++++++++++++++++++++++++++++-\n t/t1300-repo-config.sh |   43 +++++++++++++++++++++++++++++++++++++\n 2 files changed, 97 insertions(+), 1 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex 6963fbe..e7581b4 100644\n--- a/config.c\n+++ b/config.c\n@@ -7,6 +7,7 @@\n  */\n #include \"cache.h\"\n #include \"exec_cmd.h\"\n+#include <glob.h>\n \n #define MAXNAME (256)\n \n@@ -111,6 +112,52 @@ static inline int iskeychar(int c)\n \treturn isalnum(c) || c == '-';\n }\n \n+static void glob_include_config(config_fn_t fn, void *data, char *pattern)\n+{\n+\tglob_t globber;\n+\tint glob_ret;\n+\tint conf_ret;\n+\tsize_t i = 0;\n+\tchar *cfile = NULL;\n+\tFILE *saved_config_file;\n+\tchar *saved_config_file_name;\n+\tint saved_config_linenr;\n+\tint saved_config_file_eof;\n+#ifdef GLOB_TILDE\n+\tint glob_flags = GLOB_TILDE;\n+#else\n+\t/* XXX: Non-GNU support for ~ expansion */\n+\tint glob_flags = 0;\n+#endif\n+\n+\tglob_ret = glob(pattern, glob_flags, NULL, &globber);\n+\n+\tif (glob_ret == GLOB_NOSPACE || glob_ret == GLOB_ABORTED) {\n+\t\tglobfree(&globber);\n+\t\tdie(\"Unable to include config with pattern %s\", pattern);\n+\t}\n+\n+\tfor (i = 0; i < globber.gl_pathc; i++) {\n+\t\tcfile = globber.gl_pathv[i];\n+\n+\t\t/* Save away global state for including another file */\n+\t\tsaved_config_file = config_file;\n+\t\tsaved_config_file_name = config_file_name;\n+\t\tsaved_config_linenr = config_linenr;\n+\t\tsaved_config_file_eof = config_file_eof;\n+\n+\t\tconf_ret = git_config_from_file(fn, cfile, data);\n+\n+\t\t/* Restore it again */\n+\t\tconfig_file = saved_config_file;\n+\t\tconfig_file_name = saved_config_file_name;\n+\t\tconfig_linenr = saved_config_linenr;\n+\t\tconfig_file_eof = saved_config_file_eof;\n+\t}\n+\n+\tglobfree(&globber);\n+}\n+\n static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)\n {\n \tint c;\n@@ -139,7 +186,13 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)\n \t\tif (!value)\n \t\t\treturn -1;\n \t}\n-\treturn fn(name, value, data);\n+\n+\tif (!strcmp(name, \"voodoo.include\")) {\n+\t\tglob_include_config(fn, data, value);\n+\t\treturn 0;\n+\t} else {\n+\t\treturn fn(name, value, data);\n+\t}\n }\n \n static int get_extended_base_var(char *name, int baselen, int c)\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex f11f98c..4df6658 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -824,4 +824,47 @@ test_expect_success 'check split_cmdline return' \"\n \ttest_must_fail git merge master\n \t\"\n \n+cat > .git/config << EOF\n+[some]\n+\tvariable = blah\n+[voodoo]\n+\tinclude = .git/more_config_*\n+EOF\n+\n+cat > .git/more_config_1 << EOF\n+[another]\n+\tvariable = blah blah\n+EOF\n+\n+cat > .git/more_config_2 << EOF\n+[evenmore]\n+\tvariable = blah bluh \n+EOF\n+\n+test_expect_success 'The voodoo include variable is hidden from us' \\\n+    'test_must_fail git config --get voodoo.include'\n+test_expect_success 'get some included variable' \\\n+    'git config --get some.variable'\n+test_expect_success 'get another included variable' \\\n+    'git config --get another.variable'\n+test_expect_success 'get evenmore included variable' \\\n+    'git config --get evenmore.variable'\n+\n+rm .git/more_config*\n+\n+cat > .git/config << EOF\n+[voodoo]\n+\tinclude = .git/more_config_*\n+EOF\n+\n+cat > .git/more_config_1 << EOF\n+[foo]\n+    bar = zar\n+[voodoo]\n+\tinclude = .git/more_config_*\n+EOF\n+\n+test_expect_success 'circular config inclusion' \\\n+    'test_must_fail git config --get foo.bar'\n+\n test_done\n-- \n1.7.1.dirty\n"},{"id":"141115","messageId":"AANLkTik6z4cvUzjfq-q61tgk_MhqWKc_A55i3VauPSQC@mail.gmail.com","threadId":"23291","inReplyTo":"1273180440-8641-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-05-07T06:00:51Z","receivedAt":"2010-05-07T06:00:51Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Thu, May 6, 2010 at 23:14, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>\n> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n\nSo you don't agree to the Developer's Certificate of Origin, don't you?\n\nBert\n"},{"id":"141131","messageId":"AANLkTinhh8TXY9r9Jf394YKYXDxpU65qjg7MbPcb12Ls@mail.gmail.com","threadId":"23291","inReplyTo":"AANLkTik6z4cvUzjfq-q61tgk_MhqWKc_A55i3VauPSQC@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-07T16:56:17Z","receivedAt":"2010-05-07T16:56:17Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, May 7, 2010 at 06:00, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> On Thu, May 6, 2010 at 23:14, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>\n>> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>\n> So you don't agree to the Developer's Certificate of Origin, don't you?\n\nSigned-off-by is for \"if you want your work included in git.git\"\n(according to Documentation/SubmittingPatches). I don't think this\npatch is ready for inclusion as-is, but I wanted to solicit comments\non the general approach.\n"},{"id":"141137","messageId":"AANLkTilp0d28QMs_K7cVrfqmkzeqs8FTJbU1oeuUy7V6@mail.gmail.com","threadId":"23291","inReplyTo":"AANLkTinhh8TXY9r9Jf394YKYXDxpU65qjg7MbPcb12Ls@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-05-07T18:29:27Z","receivedAt":"2010-05-07T18:29:27Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, May 7, 2010 at 18:56, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> On Fri, May 7, 2010 at 06:00, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>> On Thu, May 6, 2010 at 23:14, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>>\n>>> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>\n>> So you don't agree to the Developer's Certificate of Origin, don't you?\n>\n> Signed-off-by is for \"if you want your work included in git.git\"\n> (according to Documentation/SubmittingPatches). I don't think this\n> patch is ready for inclusion as-is, but I wanted to solicit comments\n> on the general approach.\n>\n\nCan you please quote SubmittingPatches for your argumentation.\n\nI think you mix technical and legal aspects of submitting patches.\n\nThank you and please note I'm not a lawyer.\n\nBert\n"},{"id":"141140","messageId":"AANLkTilG5OGjQcd1Vd1CdyOibFh4Po6jdfvSRNidrRzh@mail.gmail.com","threadId":"23291","inReplyTo":"AANLkTilp0d28QMs_K7cVrfqmkzeqs8FTJbU1oeuUy7V6@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-07T18:58:47Z","receivedAt":"2010-05-07T18:58:47Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, May 7, 2010 at 18:29, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> On Fri, May 7, 2010 at 18:56, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>> On Fri, May 7, 2010 at 06:00, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>>> On Thu, May 6, 2010 at 23:14, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>>>\n>>>> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>>\n>>> So you don't agree to the Developer's Certificate of Origin, don't you?\n>>\n>> Signed-off-by is for \"if you want your work included in git.git\"\n>> (according to Documentation/SubmittingPatches). I don't think this\n>> patch is ready for inclusion as-is, but I wanted to solicit comments\n>> on the general approach.\n>>\n>\n> Can you please quote SubmittingPatches for your argumentation.\n\nI already did, but here's the full paragraph I quoted from, for\nreference:\n\n\t- if you want your work included in git.git, add a\n\t  \"Signed-off-by: Your Name <you@example.com>\" line to the\n\t  commit message (or just use the option \"-s\" when\n\t  committing) to confirm that you agree to the Developer's\n\t  Certificate of Origin\n\nI'm not seeking to include this work as-is in Git, so I added a\nNot-signed-off-by line to make that clear (as if all the bugs didn't\ndo that already).\n\nI do agree to the Developer's Certificate of Origin, but just read the\n\"Not-signed-off-by\" as \"you really don't want to apply this in its\ncurrent state\". I'm asking for comments so that I can produce an\nappliable patch, that one will have a Signed-off-by line.\n"},{"id":"141141","messageId":"v2g8c9a061005071202h820ef8a6nab023868fec28222@mail.gmail.com","threadId":"23291","inReplyTo":"AANLkTilG5OGjQcd1Vd1CdyOibFh4Po6jdfvSRNidrRzh@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-05-07T19:02:49Z","receivedAt":"2010-05-07T19:02:49Z","isPatch":true,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Fri, May 7, 2010 at 11:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> On Fri, May 7, 2010 at 18:29, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>> On Fri, May 7, 2010 at 18:56, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>> On Fri, May 7, 2010 at 06:00, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>>>> On Thu, May 6, 2010 at 23:14, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>>>>\n>>>>> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>>>\n>>>> So you don't agree to the Developer's Certificate of Origin, don't you?\n>>>\n>>> Signed-off-by is for \"if you want your work included in git.git\"\n>>> (according to Documentation/SubmittingPatches). I don't think this\n>>> patch is ready for inclusion as-is, but I wanted to solicit comments\n>>> on the general approach.\n>>>\n>>\n>> Can you please quote SubmittingPatches for your argumentation.\n>\n> I already did, but here's the full paragraph I quoted from, for\n> reference:\n>\n>        - if you want your work included in git.git, add a\n>          \"Signed-off-by: Your Name <you@example.com>\" line to the\n>          commit message (or just use the option \"-s\" when\n>          committing) to confirm that you agree to the Developer's\n>          Certificate of Origin\n>\n> I'm not seeking to include this work as-is in Git, so I added a\n> Not-signed-off-by line to make that clear (as if all the bugs didn't\n> do that already).\n>\n> I do agree to the Developer's Certificate of Origin, but just read the\n> \"Not-signed-off-by\" as \"you really don't want to apply this in its\n> current state\". I'm asking for comments so that I can produce an\n> appliable patch, that one will have a Signed-off-by line.\n>\n\nHaving \"[RFC]\" instead of \"[PATCH]\" as the subject prefix is typically\nconsidered sufficient to indicate \"this isn't actually intended for\ninclusion\".\n"},{"id":"141163","messageId":"AANLkTimziTKL13VKIOcaS1TX1F_xvTVjH8Q398Yx36Us@mail.gmail.com","threadId":"23291","inReplyTo":"AANLkTilG5OGjQcd1Vd1CdyOibFh4Po6jdfvSRNidrRzh@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-05-07T19:52:07Z","receivedAt":"2010-05-07T19:52:07Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, May 7, 2010 at 20:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> On Fri, May 7, 2010 at 18:29, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>> On Fri, May 7, 2010 at 18:56, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>> On Fri, May 7, 2010 at 06:00, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>>>> On Thu, May 6, 2010 at 23:14, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>>>>>\n>>>>> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>>>\n>>>> So you don't agree to the Developer's Certificate of Origin, don't you?\n>>>\n>>> Signed-off-by is for \"if you want your work included in git.git\"\n>>> (according to Documentation/SubmittingPatches). I don't think this\n>>> patch is ready for inclusion as-is, but I wanted to solicit comments\n>>> on the general approach.\n>>>\n>>\n>> Can you please quote SubmittingPatches for your argumentation.\n>\n> I already did, but here's the full paragraph I quoted from, for\n> reference:\n>\n>        - if you want your work included in git.git, add a\n>          \"Signed-off-by: Your Name <you@example.com>\" line to the\n>          commit message (or just use the option \"-s\" when\n>          committing) to confirm that you agree to the Developer's\n>          Certificate of Origin\n>\n\nBut where does the Developer's Certificate of Origin talks about\nnon-legal aspects of patch submitting? E.g. correctness, quality, ...\n\nI think the part \"if you want your work included in git.git\" is very\nmisleading in this paragraph, and I propose to remove it.\n\n> I'm not seeking to include this work as-is in Git, so I added a\n> Not-signed-off-by line to make that clear (as if all the bugs didn't\n> do that already).\n>\n> I do agree to the Developer's Certificate of Origin, but just read the\n> \"Not-signed-off-by\" as \"you really don't want to apply this in its\n> current state\". I'm asking for comments so that I can produce an\n> appliable patch, that one will have a Signed-off-by line.\n>\n\nAnd thats exactly where you mixed legal and technical aspects of patch\nsubmitting, and others may not (especially me, obviously). The S-o-b\nline has nothing to do with the technical aspect, or the quality, of\nthe patch. Adding \"Not-signed-off-by\" (or even worse: changing it\nlater to Signed-off-by) could actually mean that you stole the code\nfrom someone else.\n\nBert\n"},{"id":"141168","messageId":"1273263079-885-1-git-send-email-avarab@gmail.com","threadId":"23291","inReplyTo":"AANLkTimziTKL13VKIOcaS1TX1F_xvTVjH8Q398Yx36Us@mail.gmail.com","subject":"[PATCH/RFC v2] Hacky version of a glob() driven config include","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-07T20:11:19Z","receivedAt":"2010-05-07T20:11:19Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Add support for a special `voodoo.include` config variable. Its\ncontents will be globbed, and the files it expands to included as\nconfig files.\n\nThis enables support for keeping around a ~/.gitconfig.d/* directory,\nor for distros to keep a /etc/gitconfig.d/* directory. Some use cases:\n\n  * Keep secret portions of the Git config file separate,\n    e.g. github.token. Useful if the ~/.gitconfig itself is kept in\n    a public Git repository.\n\n  * Ability to selectively include config libraries. You could include\n    e.g. ~/.gitconfig.d/pretty-colors.ini or\n    ~/.gitconfig.d/better-submodule-handling.ini from a remote source.\n\nKnown bugs:\n\n  * Breaks the model of being able to *set* config values. That\n    doesn't work for the included files, i.e. setting a value that\n    might be considered derived from a value in an included file won't\n    end up in the \"right\" place. Maybe not a bug.\n\n  * Errors in the git_config_from_file() call in glob_include_config()\n    aren't passed upwards.\n\n  * It relies on the GNU GLOB_TILDE extension with no\n    alternative. That can be done by calling getenv(\"HOME\") and\n    s/~/$home/.\n\n  * The whole bit with saving/restoring global state for config\n    inclusion is evil, but then again so is the global state.\n\n  * We don't check for recursion. But Git gives up eventually after\n    after spewing a *lot* of duplicate entry errors. Not sure how to\n    do this sanely w/symlinks.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\nOn Fri, May 7, 2010 at 19:52, Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n\n> But where does the Developer's Certificate of Origin talks about\n> non-legal aspects of patch submitting? E.g. correctness, quality, ...\n>\n> I think the part \"if you want your work included in git.git\" is very\n> misleading in this paragraph, and I propose to remove it.\n\nFair enough. My reading of it was literal, i.e. `if (want_inclusion &&\nDCO) { -s }`. Since I didn't want inclusion for the patch I didn't add a SOB.\n\nHere's a version v2 of the patch with a Signed-off-by, and a better\ncommit message.\n\n config.c               |   55 +++++++++++++++++++++++++++++++++++++++++++++++-\n t/t1300-repo-config.sh |   43 +++++++++++++++++++++++++++++++++++++\n 2 files changed, 97 insertions(+), 1 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex 6963fbe..e7581b4 100644\n--- a/config.c\n+++ b/config.c\n@@ -7,6 +7,7 @@\n  */\n #include \"cache.h\"\n #include \"exec_cmd.h\"\n+#include <glob.h>\n \n #define MAXNAME (256)\n \n@@ -111,6 +112,52 @@ static inline int iskeychar(int c)\n \treturn isalnum(c) || c == '-';\n }\n \n+static void glob_include_config(config_fn_t fn, void *data, char *pattern)\n+{\n+\tglob_t globber;\n+\tint glob_ret;\n+\tint conf_ret;\n+\tsize_t i = 0;\n+\tchar *cfile = NULL;\n+\tFILE *saved_config_file;\n+\tchar *saved_config_file_name;\n+\tint saved_config_linenr;\n+\tint saved_config_file_eof;\n+#ifdef GLOB_TILDE\n+\tint glob_flags = GLOB_TILDE;\n+#else\n+\t/* XXX: Non-GNU support for ~ expansion */\n+\tint glob_flags = 0;\n+#endif\n+\n+\tglob_ret = glob(pattern, glob_flags, NULL, &globber);\n+\n+\tif (glob_ret == GLOB_NOSPACE || glob_ret == GLOB_ABORTED) {\n+\t\tglobfree(&globber);\n+\t\tdie(\"Unable to include config with pattern %s\", pattern);\n+\t}\n+\n+\tfor (i = 0; i < globber.gl_pathc; i++) {\n+\t\tcfile = globber.gl_pathv[i];\n+\n+\t\t/* Save away global state for including another file */\n+\t\tsaved_config_file = config_file;\n+\t\tsaved_config_file_name = config_file_name;\n+\t\tsaved_config_linenr = config_linenr;\n+\t\tsaved_config_file_eof = config_file_eof;\n+\n+\t\tconf_ret = git_config_from_file(fn, cfile, data);\n+\n+\t\t/* Restore it again */\n+\t\tconfig_file = saved_config_file;\n+\t\tconfig_file_name = saved_config_file_name;\n+\t\tconfig_linenr = saved_config_linenr;\n+\t\tconfig_file_eof = saved_config_file_eof;\n+\t}\n+\n+\tglobfree(&globber);\n+}\n+\n static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)\n {\n \tint c;\n@@ -139,7 +186,13 @@ static int get_value(config_fn_t fn, void *data, char *name, unsigned int len)\n \t\tif (!value)\n \t\t\treturn -1;\n \t}\n-\treturn fn(name, value, data);\n+\n+\tif (!strcmp(name, \"voodoo.include\")) {\n+\t\tglob_include_config(fn, data, value);\n+\t\treturn 0;\n+\t} else {\n+\t\treturn fn(name, value, data);\n+\t}\n }\n \n static int get_extended_base_var(char *name, int baselen, int c)\ndiff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\nindex f11f98c..4df6658 100755\n--- a/t/t1300-repo-config.sh\n+++ b/t/t1300-repo-config.sh\n@@ -824,4 +824,47 @@ test_expect_success 'check split_cmdline return' \"\n \ttest_must_fail git merge master\n \t\"\n \n+cat > .git/config << EOF\n+[some]\n+\tvariable = blah\n+[voodoo]\n+\tinclude = .git/more_config_*\n+EOF\n+\n+cat > .git/more_config_1 << EOF\n+[another]\n+\tvariable = blah blah\n+EOF\n+\n+cat > .git/more_config_2 << EOF\n+[evenmore]\n+\tvariable = blah bluh \n+EOF\n+\n+test_expect_success 'The voodoo include variable is hidden from us' \\\n+    'test_must_fail git config --get voodoo.include'\n+test_expect_success 'get some included variable' \\\n+    'git config --get some.variable'\n+test_expect_success 'get another included variable' \\\n+    'git config --get another.variable'\n+test_expect_success 'get evenmore included variable' \\\n+    'git config --get evenmore.variable'\n+\n+rm .git/more_config*\n+\n+cat > .git/config << EOF\n+[voodoo]\n+\tinclude = .git/more_config_*\n+EOF\n+\n+cat > .git/more_config_1 << EOF\n+[foo]\n+    bar = zar\n+[voodoo]\n+\tinclude = .git/more_config_*\n+EOF\n+\n+test_expect_success 'circular config inclusion' \\\n+    'test_must_fail git config --get foo.bar'\n+\n test_done\n-- \n1.7.1.dirty\n"},{"id":"141181","messageId":"m3k4rfe90n.fsf@localhost.localdomain","threadId":"23291","inReplyTo":"1273180440-8641-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-07T20:46:17Z","receivedAt":"2010-05-07T20:46:17Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:\n\n> This is not ready for inclusion in anything. Commiting for RFC on\n> whether this way of doing it is sane in theory.\n\nI think this is a good idea at least in theory.\n \n> Known bugs:\n> \n>   * Breaks the model of being able to *set* config values. That\n>     doesn't work for the included files. Maybe not a bug.\n\nErrr... do I understand correctly that it simply means that you are\nnot able to set config values that came from included files, in\nincluded files?\n\nThis is quite serious limitation.\n\n> \n>   * Errors in the git_config_from_file() call in glob_include_config()\n>     aren't passed upwards.\n\nHmmm...\n\n> \n>   * It relies on the GNU GLOB_TILDE extension with no\n>     alternative. That can be done by calling getenv(\"HOME\") and\n>     s/~/$home/.\n\n\"git config --path <variable>\" expands leading '~' to $HOME, and ~user\nto home directory of given user.  Why not use this?\n\n> \n>   * The whole bit with saving/restoring global state for config\n>     inclusion is evil, but then again so is the global state.\n\nWhy not encapsulate those global variables in a struct, passed to\nappropriate functions, with a global variable holding an instance of\nsuch struct (IIRC similarly to what is done for \"the_index\").\n\n> \n>   * We don't check for recursion. But Git gives up eventually after\n>     after spewing a *lot* of duplicate entry errors. Not sure how to\n>     do this sanely w/symlinks.\n\nThe alternates mechanism has some depth limit; why not use it also for\nconfig file inclusion?  The machanism is quite similar...\n\n> \n> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n\nYou can simply do not add Signed-off-by for an RFC patch...\n\n> ---\n> \n> > On Sun, Apr 4, 2010 at 07:50, Eli Barzilay <eli@barzilay.org> wrote:\n> > > Isn't it better to have a way to include files instead?\n> >\n> > Probably yes. Programs like Apache HTTPD, rsyslog and others just use\n> > ${foo}conf.d by convention by supporting config inclusion.\n> \n> Here's an evil implementation of this. I know the code is horrid &\n> buggy (see above). But is the general idea sane. I thought it would be\n> better to submit this for comments before I went further with it.\n> \n>  config.c               |   55 +++++++++++++++++++++++++++++++++++++++++++++++-\n>  t/t1300-repo-config.sh |   43 +++++++++++++++++++++++++++++++++++++\n>  2 files changed, 97 insertions(+), 1 deletions(-)\n\nNo documentation.\n \n[...]\n> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\n> index f11f98c..4df6658 100755\n> --- a/t/t1300-repo-config.sh\n> +++ b/t/t1300-repo-config.sh\n> @@ -824,4 +824,47 @@ test_expect_success 'check split_cmdline return' \"\n>  \ttest_must_fail git merge master\n>  \t\"\n>  \n> +cat > .git/config << EOF\n> +[some]\n> +\tvariable = blah\n> +[voodoo]\n> +\tinclude = .git/more_config_*\n> +EOF\n\nI don't like this syntax.\n\nFirst, it forces git-config to hide all 'include' keys.  I think there\nmight be some legitimate <section>.include config variables (perhaps\noutside git-core); with this patch they are impossible.\n\n\nSecond, I guess that the section name has absolutely no meaning here.\nIf included config file has section.key config variable, i.e.:\n\n  [section]\n        key = value\n\nthe variable in master config file (visible by git-config) would not\nbe voodoo.section.key.\n\n\nThird, what happens with the sections in master config file?  If I\nhave the following in .git/config\n\n  [voodoo]\n        var1 = val1\n        include = .git/more_config\n        var2 = val2\n\nand the .git/more_config has\n\n  [foo]\n        bar = baz\n\nwould \"git config --list\" see 'voodoo.var2' (i.e. sections in included\nfile does not change parsing of master file), or would it see\n'foo.var2'?\n\n\nI would propose\n\n  include .git/more_config_*\n\nif not for the fast that it would trip older git.  Perhaps\n\n  [include \".git/more_config_*\"]\n\nor\n\n  [include .git/more_config_*]\n\nor\n\n  ## include \".git/more_config_*\"\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"141198","messageId":"AANLkTinCaPrThtuQd7tUFxNNn9KUx9v3_PXnH_6C8yco@mail.gmail.com","threadId":"23291","inReplyTo":"m3k4rfe90n.fsf@localhost.localdomain","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-07T22:15:18Z","receivedAt":"2010-05-07T22:15:18Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, May 7, 2010 at 20:46, Jakub Narebski <jnareb@gmail.com> wrote:\n> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:\n>\n>> This is not ready for inclusion in anything. Commiting for RFC on\n>> whether this way of doing it is sane in theory.\n>\n> I think this is a good idea at least in theory.\n\nThanks, and thanks for all your comments below. They were very useful.\n\n>> Known bugs:\n>>\n>>   * Breaks the model of being able to *set* config values. That\n>>     doesn't work for the included files. Maybe not a bug.\n>\n> Errr... do I understand correctly that it simply means that you are\n> not able to set config values that came from included files, in\n> included files?\n>\n> This is quite serious limitation.\n\nIt is. And recap, you can now you can set Git's config in either\nplaces .git/config, ~/.gitconfig and $prefix/etc/gitconfig.\n\nWith inclusion this is a bit more complex. If my ~/.gitconfig includes\na seekrt.key=foobar via an include in ~/.gitconfig/seekrt, what should\n`git config --global seekrt.key newkey` do? How about `git config\n--global seekrt.some_new_value blah`?\n\nI think it's best to not try to get into that mess and just let the\nuser manage included files manually, or with `git config --file`.\n\n>>   * Errors in the git_config_from_file() call in glob_include_config()\n>>     aren't passed upwards.\n>\n> Hmmm...\n>\n>>\n>>   * It relies on the GNU GLOB_TILDE extension with no\n>>     alternative. That can be done by calling getenv(\"HOME\") and\n>>     s/~/$home/.\n>\n> \"git config --path <variable>\" expands leading '~' to $HOME, and ~user\n> to home directory of given user.  Why not use this?\n\nI didn't spot it. expand_user_path() does do everything I need,\nyippie! I'll use that then.\n\n>>   * The whole bit with saving/restoring global state for config\n>>     inclusion is evil, but then again so is the global state.\n>\n> Why not encapsulate those global variables in a struct, passed to\n> appropriate functions, with a global variable holding an instance of\n> such struct (IIRC similarly to what is done for \"the_index\").\n\nThat's indeed the sane way to go. I'll do that (and look at\nthe_index).\n\n>>   * We don't check for recursion. But Git gives up eventually after\n>>     after spewing a *lot* of duplicate entry errors. Not sure how to\n>>     do this sanely w/symlinks.\n>\n> The alternates mechanism has some depth limit; why not use it also for\n> config file inclusion?  The machanism is quite similar...\n\nYet another example of prior art in git itself I have to check out,\nthanks.\n\n>> Not-signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>\n> You can simply do not add Signed-off-by for an RFC patch...\n>\n>> ---\n>>\n>> > On Sun, Apr 4, 2010 at 07:50, Eli Barzilay <eli@barzilay.org> wrote:\n>> > > Isn't it better to have a way to include files instead?\n>> >\n>> > Probably yes. Programs like Apache HTTPD, rsyslog and others just use\n>> > ${foo}conf.d by convention by supporting config inclusion.\n>>\n>> Here's an evil implementation of this. I know the code is horrid &\n>> buggy (see above). But is the general idea sane. I thought it would be\n>> better to submit this for comments before I went further with it.\n>>\n>>  config.c               |   55 +++++++++++++++++++++++++++++++++++++++++++++++-\n>>  t/t1300-repo-config.sh |   43 +++++++++++++++++++++++++++++++++++++\n>>  2 files changed, 97 insertions(+), 1 deletions(-)\n>\n> No documentation.\n\nA final patch will have that. Since some of the semantics are \"munges\nyour .gitconfig\" (a bug). I'll write dosc for it once it's behaving.\n\n> [...]\n>> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh\n>> index f11f98c..4df6658 100755\n>> --- a/t/t1300-repo-config.sh\n>> +++ b/t/t1300-repo-config.sh\n>> @@ -824,4 +824,47 @@ test_expect_success 'check split_cmdline return' \"\n>>       test_must_fail git merge master\n>>       \"\n>>\n>> +cat > .git/config << EOF\n>> +[some]\n>> +     variable = blah\n>> +[voodoo]\n>> +     include = .git/more_config_*\n>> +EOF\n>\n> I don't like this syntax.\n\nMe neither.\n\n> First, it forces git-config to hide all 'include' keys.  I think there\n> might be some legitimate <section>.include config variables (perhaps\n> outside git-core); with this patch they are impossible.\n\nIt's only hiding the full 'voodoo.include' key currently, you can\nstill have e.g. 'bleh.include'.\n\n> Second, I guess that the section name has absolutely no meaning here.\n> If included config file has section.key config variable, i.e.:\n>\n>  [section]\n>        key = value\n>\n> the variable in master config file (visible by git-config) would not\n> be voodoo.section.key.\n\nNo. All includes are done at the top level. The end result should be\nequivalent to having used cat(1) to stitch a bunch of config files\ntogether.\n\n> Third, what happens with the sections in master config file?  If I\n> have the following in .git/config\n>\n>  [voodoo]\n>        var1 = val1\n>        include = .git/more_config\n>        var2 = val2\n>\n> and the .git/more_config has\n>\n>  [foo]\n>        bar = baz\n>\n> would \"git config --list\" see 'voodoo.var2' (i.e. sections in included\n> file does not change parsing of master file), or would it see\n> 'foo.var2'?\n\nOnly voodoo.include should be hidden, nothing else. But let's move on\nto..\n\n> I would propose\n>\n>  include .git/more_config_*\n>\n> if not for the fast that it would trip older git.  Perhaps\n\n>  ## include \".git/more_config_*\"\n\nProbably not a good idea to mix up comments & configuration like\nthat. Some (semi-broken) parsers of .gitconfig also use INI parsers to\nparse it, which breaks on # comments. Those are already broken, but it\nwould be nice if a feature didn't require them.\n\n>  [include .git/more_config_*]\n\nSyntax error on older Gits.\n\n>  [include \".git/more_config_*\"]\n\nI like this one the best. It's also easy to modify the parser (so it\ndoesn't think it's a section) to handle it. And it doesn't incur the\nconfusion of looking like a normal configuration variable.\n"},{"id":"141207","messageId":"201005080143.21172.jnareb@gmail.com","threadId":"23291","inReplyTo":"AANLkTinCaPrThtuQd7tUFxNNn9KUx9v3_PXnH_6C8yco@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-07T23:43:16Z","receivedAt":"2010-05-07T23:43:16Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 8 May 2010, Ævar Arnfjörð Bjarmason wrote:\n> On Fri, May 7, 2010 at 20:46, Jakub Narebski <jnareb@gmail.com> wrote:\n> > Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:\n\n> > > Known bugs:\n> > >\n> > >   * Breaks the model of being able to *set* config values. That\n> > >     doesn't work for the included files. Maybe not a bug.\n> >\n> > Errr... do I understand correctly that it simply means that you are\n> > not able to set config values that came from included files, in\n> > included files?\n> >\n> > This is quite serious limitation.\n\nI was wrong there; this is not even a problem.\n\n> It is. And recap, you can now you can set Git's config in either\n> places .git/config, ~/.gitconfig and $prefix/etc/gitconfig.\n> \n> With inclusion this is a bit more complex. If my ~/.gitconfig includes\n> a seekrt.key=foobar via an include in ~/.gitconfig/seekrt, what should\n> `git config --global seekrt.key newkey` do? How about `git config\n> --global seekrt.some_new_value blah`?\n> \n> I think it's best to not try to get into that mess and just let the\n> user manage included files manually, or with `git config --file`.\n\nThis is not a problem: while \"git config --get foo.bar\" would search\nthrough $GIT_DIR/config, ~/.gitconfig and /etc/gitconfig (and with\nyour addition also included files), \"git config foo.bar baz\" would set\nfoo.bar to baz always in per-repository config file (in absence of\n--global / --system / --file=<file> option).\n\nSo this would be simply an extension of existing situation.  Not a bug.\n\n> > >   * The whole bit with saving/restoring global state for config\n> > >     inclusion is evil, but then again so is the global state.\n> >\n> > Why not encapsulate those global variables in a struct, passed to\n> > appropriate functions, with a global variable holding an instance of\n> > such struct (IIRC similarly to what is done for \"the_index\").\n> \n> That's indeed the sane way to go. I'll do that (and look at\n> the_index).\n\nNote that variable might not be called the_index...\n\n[...]\n> > > +cat > .git/config << EOF\n> > > +[some]\n> > > +     variable = blah\n> > > +[voodoo]\n> > > +     include = .git/more_config_*\n> > > +EOF\n> >\n> > I don't like this syntax.\n> \n> Me neither.\n> \n> > First, it forces git-config to hide all 'include' keys.  I think\n> > there might be some legitimate <section>.include config variables\n> > (perhaps outside git-core); with this patch they are impossible.\n\nHere I didn't notice that it has to be voodoo.include, and not any other\nfully qualified variable name, i.e. section name must be voodoo.\n\n> It's only hiding the full 'voodoo.include' key currently, you can\n> still have e.g. 'bleh.include'.\n\nvoodoo.include shows that black magic voodoo; include.file could be\na bit better.\n\n> > I would propose\n> >\n> >  include .git/more_config_*\n> >\n> > if not for the fast that it would trip older git.  Perhaps\n> >\n> >  ## include \".git/more_config_*\"\n\nOr perhaps\n\n  #include \".git/more_config_*\"\n\n:-)\n\n> \n> Probably not a good idea to mix up comments & configuration like\n> that. Some (semi-broken) parsers of .gitconfig also use INI parsers to\n> parse it, which breaks on # comments. Those are already broken, but it\n> would be nice if a feature didn't require them.\n\nBTW IIRC ini-files format (at least one of them) allows for ';'-prefixed\nline comments (comment must be on its own line); I wonder how it is with \nini-like git config format.\n\nBut in some ini-formats definition we have that both the hash mark (#) \nand the semicolon (;) are comment characters.\n\n> \n> >  [include .git/more_config_*]\n> \n> Syntax error on older Gits.\n> \n> >  [include \".git/more_config_*\"]\n> \n> I like this one the best. It's also easy to modify the parser (so it\n> doesn't think it's a section) to handle it. And it doesn't incur the\n> confusion of looking like a normal configuration variable.\n\nWhat I don't like with this proposal is that one could write\n\n  [include \".git/more_config_*\"]\n  \tfoo = bar\n\nWhich is confusing.\n\nBut perhaps we can break backwards compatibility here.  I don't know...\n\n  <include .git/more_config_*>\n  [[.git/more_config_*]]\n  {{.git/more_config_*}}\n  [=.git/more_config_*=]\n  [@.git/more_config_*]\n  %include \".git/more_config_*\"\n  @INCLUDE = .git/more_config_* \n\n-- \nJakub Narebski\nPoland\n"},{"id":"141215","messageId":"u2p46dff0321005071930n21de08bcv62d88377f082521@mail.gmail.com","threadId":"23291","inReplyTo":"201005080143.21172.jnareb@gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2010-05-08T02:30:19Z","receivedAt":"2010-05-08T02:30:19Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":">\n> But perhaps we can break backwards compatibility here.  I don't know...\n>\nI think we can. Because config file is not in repository, so if your\nolder git doesn't support it, you should not use this new syntax.\n"},{"id":"141225","messageId":"20100508050632.GE14998@coredump.intra.peff.net","threadId":"23291","inReplyTo":"1273180440-8641-1-git-send-email-avarab@gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-08T05:06:32Z","receivedAt":"2010-05-08T05:06:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 06, 2010 at 09:14:00PM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> This is not ready for inclusion in anything. Commiting for RFC on\n> whether this way of doing it is sane in theory.\n\nI think the goal of having globbing include files is reasonable.\n\n>   * It relies on the GNU GLOB_TILDE extension with no\n>     alternative. That can be done by calling getenv(\"HOME\") and\n>     s/~/$home/.\n\nWe already have expand_user_path which handles ~ properly (it is used\nfor the values of some config entries). You could then glob the result.\n\n> +cat > .git/config << EOF\n> +[some]\n> +\tvariable = blah\n> +[voodoo]\n> +\tinclude = .git/more_config_*\n> +EOF\n\nMy eyes! The goggles do nothing!\n\nThat syntax is horrid. Wouldn't it be much simpler to introduce some\ntop-level syntax for \"include this file here\", with some very simple\nsemantics:\n\n  - the included file starts with no section. It should have its own\n    section header.\n\n  - after returning from the included file, we are in no section. You\n    need a new section header.\n\nYes, there are some complex tricks those semantics won't allow, but they\nare simple to read and understand, simple to use, and simple to\nimplement.\n\nAnd really, what is the point in supporting crap like:\n\n   $ cat .gitconfig\n   [diff]\n   #include foo\n\n   $ cat foo\n   rename = true\n\n-Peff\n"},{"id":"141236","messageId":"201005081018.59757.jnareb@gmail.com","threadId":"23291","inReplyTo":"u2p46dff0321005071930n21de08bcv62d88377f082521@mail.gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-08T08:18:58Z","receivedAt":"2010-05-08T08:18:58Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 8 May 2010, Ping Yin wrote:\n> >\n> > But perhaps we can break backwards compatibility here.  I don't know...\n> >\n> I think we can. Because config file is not in repository, so if your\n> older git doesn't support it, you should not use this new syntax.\n\nActually per-repository $GIT_DIR/config file *is* in repository... but\nis not distributed (it is not transferred on clone / fetch).\n\nThe problem with breaking backwards compatibility is when repository is\non shared filesystem (be it networked filesystem such as NFS or\nCIFS/Samba share, or portable USB (pen)drive), and can be accessed by\ndifferent versions of git.\n\n\nFrom mentioned backward-incompatibile proposals, there is one that is\nalready used (at least in some Perl modules in CPAN), namely\n\n  [@foo]\n\nsyntax, which is used by Dist::Zilla (where 'foo' is name of \"bundle\",\nwhich roughly means set of pre-defined configuration variables).  \nAlthough it does not support globbing...\n\nThe '@INCLUDE = db_config.ini' is taken from OpenInteract2::Config::Ini.\n-- \nJakub Narebski\nPoland\n"},{"id":"141238","messageId":"r2i46dff0321005080203m65cb8acak750f4ef46bf4d6e8@mail.gmail.com","threadId":"23291","inReplyTo":"201005081018.59757.jnareb@gmail.com","subject":"Re: [PATCH/RFC] Hacky version of a glob() driven config include","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2010-05-08T09:03:15Z","receivedAt":"2010-05-08T09:03:15Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Sat, May 8, 2010 at 4:18 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>\n> On Sat, 8 May 2010, Ping Yin wrote:\n> > >\n> > > But perhaps we can break backwards compatibility here.  I don't know...\n> > >\n> > I think we can. Because config file is not in repository, so if your\n> > older git doesn't support it, you should not use this new syntax.\n>\n> Actually per-repository $GIT_DIR/config file *is* in repository... but\n> is not distributed (it is not transferred on clone / fetch).\n>\n> The problem with breaking backwards compatibility is when repository is\n> on shared filesystem (be it networked filesystem such as NFS or\n> CIFS/Samba share, or portable USB (pen)drive), and can be accessed by\n> different versions of git.\n\nYou are right, i missed this case.\nHowever, If NFS is used, the git version is very likely the same. So i\nthink this case is not worth the effort to keep the backwards\ncompatibility.\n\n>\n> The '@INCLUDE = db_config.ini' is taken from OpenInteract2::Config::Ini.\n\nI prefer \"include foo\" which is used by apache, and \"@include foo\"\nwhich doesn't fail to parse when foo doesn't exist.\n"}]}