{"thread":{"id":"24837","subject":"\"git -c web.browser=w3m help -w help\" still kicks firefox","startedAt":"2010-08-23T18:05:04Z","lastAt":"2024-07-01T20:42:38Z","messageCount":11,"participants":["Junio C Hamano","Jeff King","Alex Riesen","Jonathan Nieder","Eric Raible"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"148767","messageId":"7viq3119yn.fsf@alter.siamese.dyndns.org","threadId":"24837","inReplyTo":null,"subject":"\"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-23T18:05:04Z","receivedAt":"2010-08-23T18:05:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"My firefox runs in a different \"workspace\" than what I usually look at\nwhile working, and I've beem scratching my head why \"git help -w help\"\ndoesn't seem to do anything, while I was opening a new tab every time I\ntried it.  And then I tried the command on the Subject line, only to end\nup with yet another new tab X-<.\n\nI know exactly why this happens---we save the config from the command line\non a list only so that we can apply them in the correct order after items\ncoming from files, but we do not use the saved values to pass them around\nto sub-git invocations.\n\n  8b1fa77 (Allow passing of configuration parameters in the command line, 2010-03-26)\n\nA \"trivial fix\" would be to pass this info through the execv_git_cmd()\ninterface by either exporting it via an environment variable or by\nmodifying the command line options, but I am not sure about the possible\nfallouts from such a change.  For example, does \"git -c var=value config ...\"\nwork sensibly when what \"config\" is told to do (say, remove a section)\ncontradicts with having the named var with a given value?\n\nI am wondering if this is worth fixing it in the first place.\n\nOpinions?  Patches ;-)?\n"},{"id":"148768","messageId":"20100823183857.GA22386@coredump.intra.peff.net","threadId":"24837","inReplyTo":"7viq3119yn.fsf@alter.siamese.dyndns.org","subject":"Re: \"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-23T18:38:58Z","receivedAt":"2010-08-23T18:38:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 23, 2010 at 11:05:04AM -0700, Junio C Hamano wrote:\n\n> A \"trivial fix\" would be to pass this info through the execv_git_cmd()\n> interface by either exporting it via an environment variable or by\n> modifying the command line options, but I am not sure about the possible\n> fallouts from such a change.  For example, does \"git -c var=value config ...\"\n> work sensibly when what \"config\" is told to do (say, remove a section)\n> contradicts with having the named var with a given value?\n> \n> I am wondering if this is worth fixing it in the first place.\n\nIMHO, it needs to be fixed. This bug means \"git -c foo=bar X\" silently\nignores the new value of \"foo\" if \"X\" is an external or a shell script.\nFor something like \"help\" it is a minor inconvenience, but I can\ncertainly see this causing data loss. Just in 30 seconds of grepping, I\nsee that \"git -c mergetool.keepbackup=true mergetool\" would be silently\nignored. Oops.\n\nThe environment is the only sensible way to pass this down, because we\nneed to hit not just externals, but things like \"git config\" invocations\nfrom shell scripts. IOW, \"git -c\" really is about executing in a\nsub-environment that pretends that config is set. Obviously we would\nneed to quote and unquote when using the environment as a transport (or\ndo something horrible like making a temporary config file and pointing\nat it through the environment).\n\nAs for \"git config\", I would assume that \"-c\" parameters impact how\nconfig itself behaves, but have no bearing at all on actual\nconfiguration that it writes. I don't know if that is the case now,\nthough.\n\n-Peff\n"},{"id":"148770","messageId":"AANLkTi=R6ZdD9GUO6T6uCUkF+KVPbG1FGrieOfeusKct@mail.gmail.com","threadId":"24837","inReplyTo":"7viq3119yn.fsf@alter.siamese.dyndns.org","subject":"Re: \"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2010-08-23T19:02:36Z","receivedAt":"2010-08-23T19:02:36Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Mon, Aug 23, 2010 at 20:05, Junio C Hamano <gitster@pobox.com> wrote:\n> I know exactly why this happens---we save the config from the command line\n> on a list only so that we can apply them in the correct order after items\n> coming from files, but we do not use the saved values to pass them around\n> to sub-git invocations.\n>\n>  8b1fa77 (Allow passing of configuration parameters in the command line, 2010-03-26)\n>\n> A \"trivial fix\" would be to pass this info through the execv_git_cmd()\n> interface by either exporting it via an environment variable or by\n> modifying the command line options, but I am not sure about the possible\n> fallouts from such a change.  For example, does \"git -c var=value config ...\"\n> work sensibly when what \"config\" is told to do (say, remove a section)\n> contradicts with having the named var with a given value?\n>\n> I am wondering if this is worth fixing it in the first place.\n>\n> Opinions?  Patches ;-)?\n>\n\nMaybe it is worth fixing, but on a case-by-case basis?\n\nI mean changing the execv_git_cmd interface (or create a new execv function),\nso that it can get the list of config vars to pass down to the callee. A trivial\ncase of its use would be to just pass the current config (or, more\nlikely, none).\nOr, one could give it its own list of config parameters.\n"},{"id":"148771","messageId":"20100823191600.GA2523@coredump.intra.peff.net","threadId":"24837","inReplyTo":"20100823183857.GA22386@coredump.intra.peff.net","subject":"Re: \"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-23T19:16:00Z","receivedAt":"2010-08-23T19:16:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 23, 2010 at 02:38:57PM -0400, Jeff King wrote:\n\n> The environment is the only sensible way to pass this down, because we\n> need to hit not just externals, but things like \"git config\" invocations\n> from shell scripts. IOW, \"git -c\" really is about executing in a\n> sub-environment that pretends that config is set. Obviously we would\n> need to quote and unquote when using the environment as a transport (or\n> do something horrible like making a temporary config file and pointing\n> at it through the environment).\n\nHere's a first attempt. No idea if it has any bad side effects. :)\n\n-- >8 --\nSubject: [PATCH] pass \"git -c foo=bar\" params through environment\n\nGit uses the \"-c foo=bar\" parameters to set a config\nvariable for a single git invocation. We currently do this\nby making a list in the current process and consulting that\nlist in git_config.\n\nThis works fine for built-ins, but the config changes are\nsilently ignored by subprocesses, including dashed externals\nand invocations to \"git config\" from shell scripts.\n\nThis patch instead puts them in an environment variable\nwhich we consult when looking at config (both internally and\nvia calls \"git config\").\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n cache.h  |    2 ++\n config.c |   57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---\n git.c    |    2 +-\n 3 files changed, 57 insertions(+), 4 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex d8c0a98..b76d7b3 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -974,7 +974,9 @@ extern int update_server_info(int);\n typedef int (*config_fn_t)(const char *, const char *, void *);\n extern int git_default_config(const char *, const char *, void *);\n extern int git_config_from_file(config_fn_t fn, const char *, void *);\n+extern void git_config_push_parameter(const char *text);\n extern int git_config_parse_parameter(const char *text);\n+extern int git_config_parse_environment(void);\n extern int git_config_from_parameters(config_fn_t fn, void *data);\n extern int git_config(config_fn_t fn, void *);\n extern int git_parse_ulong(const char *, unsigned long *);\ndiff --git a/config.c b/config.c\nindex 7a18bc9..15eabaf 100644\n--- a/config.c\n+++ b/config.c\n@@ -8,6 +8,7 @@\n #include \"cache.h\"\n #include \"exec_cmd.h\"\n #include \"strbuf.h\"\n+#include \"quote.h\"\n \n #define MAXNAME (256)\n \n@@ -34,6 +35,19 @@ static void lowercase(char *p)\n \t\t*p = tolower(*p);\n }\n \n+void git_config_push_parameter(const char *text)\n+{\n+\tstruct strbuf env = STRBUF_INIT;\n+\tconst char *old = getenv(\"GIT_CONFIG_PARAMETERS\");\n+\tif (old) {\n+\t\tstrbuf_addstr(&env, old);\n+\t\tstrbuf_addch(&env, ' ');\n+\t}\n+\tsq_quote_buf(&env, text);\n+\tsetenv(\"GIT_CONFIG_PARAMETERS\", env.buf, 1);\n+\tstrbuf_release(&env);\n+}\n+\n int git_config_parse_parameter(const char *text)\n {\n \tstruct config_item *ct;\n@@ -61,6 +75,37 @@ int git_config_parse_parameter(const char *text)\n \treturn 0;\n }\n \n+int git_config_parse_environment(void) {\n+\tconst char *env = getenv(\"GIT_CONFIG_PARAMETERS\");\n+\tchar *envw;\n+\tconst char **argv = NULL;\n+\tint nr = 0, alloc = 0;\n+\tint i;\n+\n+\tif (!env)\n+\t\treturn 0;\n+\t/* sq_dequote will write over it */\n+\tenvw = xstrdup(env);\n+\n+\tif (sq_dequote_to_argv(envw, &argv, &nr, &alloc) < 0) {\n+\t\tfree(envw);\n+\t\treturn error(\"bogus format in GIT_CONFIG_PARAMETERS\");\n+\t}\n+\n+\tfor (i = 0; i < nr; i++) {\n+\t\tif (git_config_parse_parameter(argv[i]) < 0) {\n+\t\t\terror(\"bogus config parameter: %s\", argv[i]);\n+\t\t\tfree(argv);\n+\t\t\tfree(envw);\n+\t\t\treturn -1;\n+\t\t}\n+\t}\n+\n+\tfree(argv);\n+\tfree(envw);\n+\treturn 0;\n+}\n+\n static int get_next_char(void)\n {\n \tint c;\n@@ -781,7 +826,14 @@ int git_config_global(void)\n \n int git_config_from_parameters(config_fn_t fn, void *data)\n {\n+\tstatic int loaded_environment;\n \tconst struct config_item *ct;\n+\n+\tif (!loaded_environment) {\n+\t\tif (git_config_parse_environment() < 0)\n+\t\t\treturn -1;\n+\t\tloaded_environment = 1;\n+\t}\n \tfor (ct = config_parameters; ct; ct = ct->next)\n \t\tif (fn(ct->name, ct->value, data) < 0)\n \t\t\treturn -1;\n@@ -820,10 +872,9 @@ int git_config(config_fn_t fn, void *data)\n \t}\n \tfree(repo_config);\n \n-\tif (config_parameters) {\n-\t\tret += git_config_from_parameters(fn, data);\n+\tret += git_config_from_parameters(fn, data);\n+\tif (config_parameters)\n \t\tfound += 1;\n-\t}\n \n \tif (found == 0)\n \t\treturn -1;\ndiff --git a/git.c b/git.c\nindex 8dda939..681f96c 100644\n--- a/git.c\n+++ b/git.c\n@@ -137,7 +137,7 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t\t\tfprintf(stderr, \"-c expects a configuration string\\n\" );\n \t\t\t\tusage(git_usage_string);\n \t\t\t}\n-\t\t\tgit_config_parse_parameter((*argv)[1]);\n+\t\t\tgit_config_push_parameter((*argv)[1]);\n \t\t\t(*argv)++;\n \t\t\t(*argc)--;\n \t\t} else {\n-- \n1.7.2.2.418.g55566.dirty\n"},{"id":"148781","messageId":"20100823203304.GB4458@coredump.intra.peff.net","threadId":"24837","inReplyTo":"AANLkTi=R6ZdD9GUO6T6uCUkF+KVPbG1FGrieOfeusKct@mail.gmail.com","subject":"Re: \"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-23T20:33:04Z","receivedAt":"2010-08-23T20:33:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 23, 2010 at 09:02:36PM +0200, Alex Riesen wrote:\n\n> Maybe it is worth fixing, but on a case-by-case basis?\n> \n> I mean changing the execv_git_cmd interface (or create a new execv\n> function), so that it can get the list of config vars to pass down to\n> the callee. A trivial case of its use would be to just pass the\n> current config (or, more likely, none).  Or, one could give it its own\n> list of config parameters.\n\nI don't think that is enough. We don't necessarily know which config\noptions will be relevant to exec'd processes. We could be running some\nuser-defined command that calls a bunch of other git commands. Or a\nhook, for that matter.\n\nWhich does bring up one interesting boundary. If I run:\n\n  git -c receive.denyDeletes=false git push\n\nwhat should happen? Obviously with cross-server communication the\nenvironment won't get passed. I am inclined to say that even for local\ncases, receive-pack should clear the string. Certainly for the sake of\nconsistency between local and remote transports, but it may also be a\nsecurity issue (in most cases, no, since you would have to be exec'ing\nreceive-pack directly, and you are clearly already running an arbitrary\ncommand, but I can see somebody perhaps crossing a setuid boundary with\nreceive-pack).\n\n-Peff\n"},{"id":"148816","messageId":"20100824050127.GC20037@burratino","threadId":"24837","inReplyTo":"20100823203304.GB4458@coredump.intra.peff.net","subject":"Re: \"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-24T05:01:27Z","receivedAt":"2010-08-24T05:01:27Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> Which does bring up one interesting boundary. If I run:\n> \n>   git -c receive.denyDeletes=false git push\n> \n> what should happen? Obviously with cross-server communication the\n> environment won't get passed. I am inclined to say that even for local\n> cases, receive-pack should clear the string.\n\nSticky.  I agree with you that that would follow the principle of\nleast surprise.\n\nOn the other hand if I use\n\n\tgit push --receive-pack='git -c receive.denyDeletes=false receive-pack'\n\nthen I would expect it to work.  I don't think this is a security\nproblem because I already could have set the remote $GIT_CONFIG just\nas easily.\n"},{"id":"148822","messageId":"20100824064114.GA20724@burratino","threadId":"24837","inReplyTo":"20100823191600.GA2523@coredump.intra.peff.net","subject":"[PATCH 2/1] do not pass \"git -c foo=bar\" params to transport helpers","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-24T06:41:14Z","receivedAt":"2010-08-24T06:41:14Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Like $GIT_CONFIG, $GIT_CONFIG_PARAMETERS needs to be suppressed by\n\"git push\" and its cousins when running local transport helpers to\nimitate remote transport well.\n\nNoticed-by: Jeff King <peff@peff.net>\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\nJeff King wrote:\n\n> Here's a first attempt. No idea if it has any bad side effects. :)\n\nHere's the transport boundary.\n\n cache.h              |    3 ++-\n config.c             |    8 ++++----\n environment.c        |    1 +\n t/t5400-send-pack.sh |   23 +++++++++++++++++++++++\n 4 files changed, 30 insertions(+), 5 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 6f50ea8..181a305 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -379,6 +379,7 @@ static inline enum object_type object_type(unsigned int mode)\n #define GRAFT_ENVIRONMENT \"GIT_GRAFT_FILE\"\n #define TEMPLATE_DIR_ENVIRONMENT \"GIT_TEMPLATE_DIR\"\n #define CONFIG_ENVIRONMENT \"GIT_CONFIG\"\n+#define CONFIG_DATA_ENVIRONMENT \"GIT_CONFIG_PARAMETERS\"\n #define EXEC_PATH_ENVIRONMENT \"GIT_EXEC_PATH\"\n #define CEILING_DIRECTORIES_ENVIRONMENT \"GIT_CEILING_DIRECTORIES\"\n #define NO_REPLACE_OBJECTS_ENVIRONMENT \"GIT_NO_REPLACE_OBJECTS\"\n@@ -397,7 +398,7 @@ static inline enum object_type object_type(unsigned int mode)\n  * environment creation or simple walk of the list.\n  * The number of non-NULL entries is available as a macro.\n  */\n-#define LOCAL_REPO_ENV_SIZE 8\n+#define LOCAL_REPO_ENV_SIZE 9\n extern const char *const local_repo_env[LOCAL_REPO_ENV_SIZE + 1];\n \n extern int is_bare_repository_cfg;\ndiff --git a/config.c b/config.c\nindex e08e32b..c2c995f 100644\n--- a/config.c\n+++ b/config.c\n@@ -38,13 +38,13 @@ static void lowercase(char *p)\n void git_config_push_parameter(const char *text)\n {\n \tstruct strbuf env = STRBUF_INIT;\n-\tconst char *old = getenv(\"GIT_CONFIG_PARAMETERS\");\n+\tconst char *old = getenv(CONFIG_DATA_ENVIRONMENT);\n \tif (old) {\n \t\tstrbuf_addstr(&env, old);\n \t\tstrbuf_addch(&env, ' ');\n \t}\n \tsq_quote_buf(&env, text);\n-\tsetenv(\"GIT_CONFIG_PARAMETERS\", env.buf, 1);\n+\tsetenv(CONFIG_DATA_ENVIRONMENT, env.buf, 1);\n \tstrbuf_release(&env);\n }\n \n@@ -76,7 +76,7 @@ int git_config_parse_parameter(const char *text)\n }\n \n int git_config_parse_environment(void) {\n-\tconst char *env = getenv(\"GIT_CONFIG_PARAMETERS\");\n+\tconst char *env = getenv(CONFIG_DATA_ENVIRONMENT);\n \tchar *envw;\n \tconst char **argv = NULL;\n \tint nr = 0, alloc = 0;\n@@ -89,7 +89,7 @@ int git_config_parse_environment(void) {\n \n \tif (sq_dequote_to_argv(envw, &argv, &nr, &alloc) < 0) {\n \t\tfree(envw);\n-\t\treturn error(\"bogus format in GIT_CONFIG_PARAMETERS\");\n+\t\treturn error(\"bogus format in \" CONFIG_DATA_ENVIRONMENT);\n \t}\n \n \tfor (i = 0; i < nr; i++) {\ndiff --git a/environment.c b/environment.c\nindex 83d38d3..a199f63 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -72,6 +72,7 @@ static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;\n const char * const local_repo_env[LOCAL_REPO_ENV_SIZE + 1] = {\n \tALTERNATE_DB_ENVIRONMENT,\n \tCONFIG_ENVIRONMENT,\n+\tCONFIG_DATA_ENVIRONMENT,\n \tDB_ENVIRONMENT,\n \tGIT_DIR_ENVIRONMENT,\n \tGIT_WORK_TREE_ENVIRONMENT,\ndiff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh\nindex c718253..5bcf0b8 100755\n--- a/t/t5400-send-pack.sh\n+++ b/t/t5400-send-pack.sh\n@@ -94,6 +94,29 @@ test_expect_success 'refuse deleting push with denyDeletes' '\n \ttest_must_fail git send-pack ./victim :extra master\n '\n \n+test_expect_success 'cannot override denyDeletes with git -c send-pack' '\n+\t(\n+\t\tcd victim &&\n+\t\ttest_might_fail git branch -D extra &&\n+\t\tgit config receive.denyDeletes true &&\n+\t\tgit branch extra master\n+\t) &&\n+\ttest_must_fail git -c receive.denyDeletes=false \\\n+\t\t\t\t\tsend-pack ./victim :extra master\n+'\n+\n+test_expect_success 'override denyDeletes with git -c receive-pack' '\n+\t(\n+\t\tcd victim &&\n+\t\ttest_might_fail git branch -D extra &&\n+\t\tgit config receive.denyDeletes true &&\n+\t\tgit branch extra master\n+\t) &&\n+\tgit send-pack \\\n+\t\t--receive-pack=\"git -c receive.denyDeletes=false receive-pack\" \\\n+\t\t./victim :extra master\n+'\n+\n test_expect_success 'denyNonFastforwards trumps --force' '\n \t(\n \t    cd victim &&\n-- \n1.7.2.2\n"},{"id":"148839","messageId":"20100824141247.GB6457@coredump.intra.peff.net","threadId":"24837","inReplyTo":"20100824050127.GC20037@burratino","subject":"Re: \"git -c web.browser=w3m help -w help\" still kicks firefox","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-24T14:12:47Z","receivedAt":"2010-08-24T14:12:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 24, 2010 at 12:01:27AM -0500, Jonathan Nieder wrote:\n\n> > Which does bring up one interesting boundary. If I run:\n> > \n> >   git -c receive.denyDeletes=false git push\n> > \n> > what should happen? Obviously with cross-server communication the\n> > environment won't get passed. I am inclined to say that even for local\n> > cases, receive-pack should clear the string.\n> \n> Sticky.  I agree with you that that would follow the principle of\n> least surprise.\n> \n> On the other hand if I use\n> \n> \tgit push --receive-pack='git -c receive.denyDeletes=false receive-pack'\n> \n> then I would expect it to work.  I don't think this is a security\n> problem because I already could have set the remote $GIT_CONFIG just\n> as easily.\n\nYeah, I think you are right. Anybody who was trying to cross a setuid\nboundary with receive-pack is already screwed unless they are cleansing\nthe environment. And I would hope that any such cleansing would be\nallow-known-good, so the new variable would be blocked along with\nGIT_CONFIG.\n\nSo I doubt we are making anything worse, security-wise. I do think we\nshould still remove the variable in the local transport for the sake of\nleast surprise, and I agree that your example above should work.\n\n-Peff\n"},{"id":"148840","messageId":"20100824141416.GC6457@coredump.intra.peff.net","threadId":"24837","inReplyTo":"20100824064114.GA20724@burratino","subject":"Re: [PATCH 2/1] do not pass \"git -c foo=bar\" params to transport helpers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-08-24T14:14:16Z","receivedAt":"2010-08-24T14:14:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 24, 2010 at 01:41:14AM -0500, Jonathan Nieder wrote:\n\n> Like $GIT_CONFIG, $GIT_CONFIG_PARAMETERS needs to be suppressed by\n> \"git push\" and its cousins when running local transport helpers to\n> imitate remote transport well.\n\nThanks, this looks good to me.\n\nThough arguably these bits:\n\n> +#define CONFIG_DATA_ENVIRONMENT \"GIT_CONFIG_PARAMETERS\"\n> [...]\n> -\tconst char *old = getenv(\"GIT_CONFIG_PARAMETERS\");\n> +\tconst char *old = getenv(CONFIG_DATA_ENVIRONMENT);\n\nShould be squashed into the original patch. :)\n\n-Peff\n"},{"id":"148863","messageId":"loom.20100824T210316-895@post.gmane.org","threadId":"24837","inReplyTo":"20100824064114.GA20724@burratino","subject":"Re: [PATCH 2/1] do not pass &quot;git -c foo=bar&quot; params to transport helpers","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2010-08-24T19:07:30Z","receivedAt":"2010-08-24T19:07:30Z","isPatch":true,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Jonathan Nieder <jrnieder <at> gmail.com> writes:\n\n>  #define GRAFT_ENVIRONMENT \"GIT_GRAFT_FILE\"\n>  #define TEMPLATE_DIR_ENVIRONMENT \"GIT_TEMPLATE_DIR\"\n>  #define CONFIG_ENVIRONMENT \"GIT_CONFIG\"\n> +#define CONFIG_DATA_ENVIRONMENT \"GIT_CONFIG_PARAMETERS\"\n>  #define EXEC_PATH_ENVIRONMENT \"GIT_EXEC_PATH\"\n>  #define CEILING_DIRECTORIES_ENVIRONMENT \"GIT_CEILING_DIRECTORIES\"\n>  #define NO_REPLACE_OBJECTS_ENVIRONMENT \"GIT_NO_REPLACE_OBJECTS\"\n\nGiven that the pattern is:\n#define foo_ENVIRONMENT \"GIT_foo\"\n\nYour addition should be:\n#define CONFIG_PARAMETERS_ENVIRONMENT \"GIT_CONFIG_PARAMETERS\"\n\nNot only that, but the first one should be:\n\n#define GRAFT_FILE_ENVIRONMENT \"GIT_GRAFT_FILE\"\n"},{"id":"497933","messageId":"xmqqh6d8vo7b.fsf@gitster.g","threadId":"24837","inReplyTo":"20100824064114.GA20724@burratino","subject":"Re: [PATCH 2/1] do not pass \"git -c foo=bar\" params to transport helpers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-01T20:42:32Z","receivedAt":"2024-07-01T20:42:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Like $GIT_CONFIG, $GIT_CONFIG_PARAMETERS needs to be suppressed by\n> \"git push\" and its cousins when running local transport helpers to\n> imitate remote transport well.\n>\n> Noticed-by: Jeff King <peff@peff.net>\n> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>\n> ---\n> Jeff King wrote:\n>\n>> Here's a first attempt. No idea if it has any bad side effects. :)\n>\n> Here's the transport boundary.\n\nFYI: there is a follow-up discussion recently.\n\nhttps://lore.kernel.org/git/20240701181916.GD3199@coredump.intra.peff.net/\n"}]}