{"thread":{"id":"64524","subject":"[BUG] `git clone '-c KEY=VALUE'` no longer works","startedAt":"2025-11-24T05:23:28Z","lastAt":"2025-11-30T18:11:08Z","messageCount":14,"participants":["Ran Ari-Gur","D. Ben Knoble","Junio C Hamano","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"531204","messageId":"CAN1UxBvk_GJjLWd0XexRxp8FFhYozGCNcodai0eqnjrhjKEh7Q@mail.gmail.com","threadId":"64524","inReplyTo":null,"subject":"[BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Ran Ari-Gur","fromEmail":"ran.arigur+git@samsara.com","sentAt":"2025-11-24T05:23:16Z","receivedAt":"2025-11-24T05:23:28Z","isPatch":false,"sender":{"key":"ran.arigur+git@samsara.com","avatar":null},"body":"Hi,\n\nThere's a small regression in Git v2.52.0; it used to be that a command of the\nform\n\n git clone '-c KEY=VALUE' ...\n\nor\n\n git clone '--config= KEY=VALUE' ...\n\nwould trim whitespace around KEY, making the command equivalent to this:\n\n git clone --config=KEY=VALUE ...\n\nThe relevant code was here:\nhttps://github.com/git/git/blob/v2.51.2/config.c#L649\n\nThat functionality was removed in this refactoring commit:\nhttps://github.com/git/git/commit/dcecac2580ef871186fdc4e9efc87815a4ce4c66\n\nAs a result, a command like the above will now fail, with an error such as this:\n\n error: invalid key: advice.detachedHead=false\n fatal: unable to write parameters to config file\n\nbecause config keys are not allowed to contain whitespace.\n\nI believe this change was unintentional; it was not mentioned in the commit\nmessage or the release notes.\n\nThis probably isn't a common case, and the project where I ran into this issue\nhas already fixed it on their end (they now pass -c and KEY=VALUE as separate\narguments); but since Git aims to ensure backward-compatibility where possible,\nI figured I should report it.\n\nThanks in advance!\n-Ran\n"},{"id":"531219","messageId":"CALnO6CBJppT3ELyu54rJvP+uqcMomJS9Nr_JTgfssn8iqG7MWA@mail.gmail.com","threadId":"64524","inReplyTo":"CAN1UxBvk_GJjLWd0XexRxp8FFhYozGCNcodai0eqnjrhjKEh7Q@mail.gmail.com","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-11-24T16:20:05Z","receivedAt":"2025-11-24T16:20:17Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Mon, Nov 24, 2025 at 12:23 AM Ran Ari-Gur wrote:\n>\n> Hi,\n>\n> There's a small regression in Git v2.52.0; it used to be that a command of the\n> form\n>\n> git clone '-c KEY=VALUE' ...\n>\n> or\n>\n> git clone '--config= KEY=VALUE' ...\n>\n> would trim whitespace around KEY, making the command equivalent to this:\n>\n> git clone --config=KEY=VALUE ...\n>\n> The relevant code was here:\n> https://github.com/git/git/blob/v2.51.2/config.c#L649\n>\n> That functionality was removed in this refactoring commit:\n> https://github.com/git/git/commit/dcecac2580ef871186fdc4e9efc87815a4ce4c66\n>\n> As a result, a command like the above will now fail, with an error such as this:\n>\n> error: invalid key: advice.detachedHead=false\n> fatal: unable to write parameters to config file\n>\n> because config keys are not allowed to contain whitespace.\n>\n> I believe this change was unintentional; it was not mentioned in the commit\n> message or the release notes.\n>\n> This probably isn't a common case, and the project where I ran into this issue\n> has already fixed it on their end (they now pass -c and KEY=VALUE as separate\n> arguments); but since Git aims to ensure backward-compatibility where possible,\n> I figured I should report it.\n>\n> Thanks in advance!\n> -Ran\n\nThanks! As far as backward compatibility, I think this behavior has\nbeen around since 2010's 8b1fa77867 (Allow passing of configuration\nparameters in the command line, 2010-03-26) which morphed via\n572e4f6a0c (Use strbufs instead of open-coded string manipulation,\n2010-03-26) into the strbuf_trim(pair[0]) that you pointed to as\ndisappearing.\n\nInterestingly, I note that we dropped the trim around pair[1] in\n06eb708f33 (config: always parse GIT_CONFIG_PARAMETERS during\ngit_config, 2011-05-24), but I don't see that discussed in the commit\nmessage either. I tried a handful of mailing list searches around\n20110524224955.GC24527@sigill.intra.peff.net, but didn't find any\nrelevant discussion (though my lore-search skills are mediocre).\n\nAnyway, authors of these now-15-year-old patchess CC'd 😅\n\n\n-- \nD. Ben Knoble\n"},{"id":"531239","messageId":"xmqq8qfvw2lh.fsf@gitster.g","threadId":"64524","inReplyTo":"CALnO6CBJppT3ELyu54rJvP+uqcMomJS9Nr_JTgfssn8iqG7MWA@mail.gmail.com","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-24T21:19:22Z","receivedAt":"2025-11-24T21:19:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"D. Ben Knoble\" writes:\n\n> On Mon, Nov 24, 2025 at 12:23 AM Ran Ari-Gur wrote:\n>>\n>> Hi,\n>>\n>> There's a small regression in Git v2.52.0; it used to be that a command of the\n>> form\n>>\n>> git clone '-c KEY=VALUE' ...\n>>\n>> or\n>>\n>> git clone '--config= KEY=VALUE' ...\n>>\n>> would trim whitespace around KEY, making the command equivalent to this:\n>>\n>> git clone --config=KEY=VALUE ...\n\nHmph, as documented in \"git help clone\",\n\n `-c` `=`::\n `--config` `=`::\n Set a configuration variable in the newly-created repository;\n this takes effect immediately after the repository is\n initialized, but before the remote history is fetched or any\n files checked out. The __ is in the same format as expected by\n linkgit:git-config[1] (e.g., `core.eol=true`).\n\nI do not offhand know if the option really used to behave as the\noriginal report described, but if\n\n\tgit clone '-c KEY=VALUE'\n\tgit clone '--config KEY=VALUE'\n\ndoes not complain-and-barf in the first place, I think that is a\nbug. The above option description clearly asks the user to give the\ndashed option (either \"-c\" or \"--config\") and \"=\" as two\nseparate arguments on the command line.\n\nInterestingly, unlike other long options described nearby, we do not\nseem to even list \"--config=K=V\" form, and that is a documentation\nbug---other options like \"server-option\" is described to use \"=\"\nafter it before its value, and to parse the \"--config K=V\", the code\nuses the same mechanism.\n\nAlso, if the user writes\n\n\tgit clone -c ' KEY=VALUE'\n\tgit clone --config ' KEY=VALUE'\n\nand we behaved as if it were \"KEY=VALUE\", that is another bug. As\ndocumented, \"key\" is in the format as expected by \"git config\", and\nwe never allowed leading or trailing whitespaces around the key\nnames.\n\nSo I dunno.\n"},{"id":"531242","messageId":"20251124225734.GB2051672@coredump.intra.peff.net","threadId":"64524","inReplyTo":"CALnO6CBJppT3ELyu54rJvP+uqcMomJS9Nr_JTgfssn8iqG7MWA@mail.gmail.com","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-11-24T22:57:34Z","receivedAt":"2025-11-24T22:57:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 24, 2025 at 11:20:05AM -0500, D. Ben Knoble wrote:\n\n> Thanks! As far as backward compatibility, I think this behavior has\n> been around since 2010's 8b1fa77867 (Allow passing of configuration\n> parameters in the command line, 2010-03-26) which morphed via\n> 572e4f6a0c (Use strbufs instead of open-coded string manipulation,\n> 2010-03-26) into the strbuf_trim(pair[0]) that you pointed to as\n> disappearing.\n> \n> Interestingly, I note that we dropped the trim around pair[1] in\n> 06eb708f33 (config: always parse GIT_CONFIG_PARAMETERS during\n> git_config, 2011-05-24), but I don't see that discussed in the commit\n> message either. I tried a handful of mailing list searches around\n> 20110524224955.GC24527@sigill.intra.peff.net, but didn't find any\n> relevant discussion (though my lore-search skills are mediocre).\n\nYeah, there's really not much (any) discussion in that thread. I don't\nrecall why I would have removed the trim on the value side, but I don't\nthink it was an intentional choice. I don't think either trim (key or\nvalue) really makes much sense. I'm kind of puzzled why we had them.\n\nI thought it first it was to be lenient in the environment list. This\ncode was originally for \"git -c foo.bar=baz\", and we are not even\nparsing it directly there. It gets shoved into GIT_CONFIG_PARAMETERS and\nthen re-parsed from there. So I think it was an attempt to be lenient\nabout writing:\n\n GIT_CONFIG_PARAMETERS=\"foo.bar=baz other.key=whatever\"\n\nBut it predates that! The environment passing came in 2b64fc894d (pass\n\"git -c foo=bar\" params through environment, 2010-08-23). And it always\nshell-quotes the names, like:\n\n GIT_CONFIG_PARAMETERS=\"'foo.bar=baz' 'other.key=whatever'\"\n\nso the extra whitespace would need to be inside the shell quotes to\nmatter. So it seems like it really was about allowing:\n\n git -c ' foo.bar=baz ' ...\n\nto work. Which seems odd. And as an added bonus, that was already\nbroken! In 1ff21c05ba (config: store \"git -c\" variables using more\nrobust format, 2021-01-12) we switched to a different format which does\nnot call git_config_parse_parameter() at all, and does not do the extra\ntrim. (The old code is still there to read the non-robust format, but\nnew Git will never write it).\n\nSo this recent refactoring of the function is left affecting only \"git\nclone -c\", which does not pass through the environment (we write the\nvariables out directly into the newly-cloned repo's config).\n\nWhile it is a change of behavior, I'm tempted to say that it was not\nsomething that was ever intended to work, and not worth going back now\nto restore.\n\n-Peff\n"},{"id":"531245","messageId":"20251124235530.GC2051672@coredump.intra.peff.net","threadId":"64524","inReplyTo":"xmqq8qfvw2lh.fsf@gitster.g","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-11-24T23:55:30Z","receivedAt":"2025-11-24T23:55:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 24, 2025 at 01:19:22PM -0800, Junio C Hamano wrote:\n\n> Hmph, as documented in \"git help clone\",\n> \n> `-c` `=`::\n> `--config` `=`::\n> Set a configuration variable in the newly-created repository;\n> this takes effect immediately after the repository is\n> initialized, but before the remote history is fetched or any\n> files checked out. The __ is in the same format as expected by\n> linkgit:git-config[1] (e.g., `core.eol=true`).\n> \n> I do not offhand know if the option really used to behave as the\n> original report described, but if\n> \n> \tgit clone '-c KEY=VALUE'\n> \tgit clone '--config KEY=VALUE'\n> \n> does not complain-and-barf in the first place, I think that is a\n> bug. The above option description clearly asks the user to give the\n> dashed option (either \"-c\" or \"--config\") and \"=\" as two\n> separate arguments on the command line.\n\nI was surprised that a single \"-c foo\" argument would work, but it makes\nsense: it is the \"stuck\" form of the short option \"-c\". So:\n\n git cmd -cfoo\n\nshould be the equivalent of:\n\n git cmd -c foo\n\nwhenever \"-c\" takes an option. It is just surprising to read because of\nthe leading space in the value.\n\nUsing the long option as a single string, like:\n\n git clone '--config KEY=VALUE'\n\ndid not ever work (and should not), because there is no option of that\nname. It is only the stuck form:\n\n git clone '--config= KEY=VALUE'\n\nwhich again makes sense from the config parser's perspective. It's just\nfunny that the first character of the option value is a space.\n\nSo I don't think there are any errors in the option-parser side. It's\njust that we were overly lenient with trimming space in interpretation\nof \" KEY=VALUE\" itself. Which has now either been corrected, or\nerroneously broken, depending on your view. ;)\n\n> Interestingly, unlike other long options described nearby, we do not\n> seem to even list \"--config=K=V\" form, and that is a documentation\n> bug---other options like \"server-option\" is described to use \"=\"\n> after it before its value, and to parse the \"--config K=V\", the code\n> uses the same mechanism.\n\nI don't think we're very consistent here. Look at --reference, --origin,\n--branch, and others. I don't know if we have an existing style\nrecommendation here (though we do recommend the \"stuck\" form in gitcli,\nwhich perhaps argues that we should be using that in our documentation).\nSo I don't know that I'd call it a bug, but it may be a good long-term\nproject to make the presentation of options more consistent.\n\n> Also, if the user writes\n> \n> \tgit clone -c ' KEY=VALUE'\n> \tgit clone --config ' KEY=VALUE'\n> \n> and we behaved as if it were \"KEY=VALUE\", that is another bug. As\n> documented, \"key\" is in the format as expected by \"git config\", and\n> we never allowed leading or trailing whitespaces around the key\n> names.\n\nSo yes, we did allow that until recently, along with:\n\n git clone -c ' foo.bar = baz'\n\nwhich keeps the space in the value \"baz\", but otherwise sets foo.bar.\n\nI agree it was certainly surprising. Despite the real-world report that\nstarted this thread, it is oddball enough that I do not think we want to\ncontinue supporting it even for historical reasons. It is not quite at\nthe level of https://xkcd.com/1172/, but especially the form that the OP\nshowed looks like a mistaken invocation that happened to work (and would\nnot work for any other option in general).\n\n-Peff\n"},{"id":"531249","messageId":"xmqqo6oqucka.fsf@gitster.g","threadId":"64524","inReplyTo":"20251124235530.GC2051672@coredump.intra.peff.net","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-25T01:27:01Z","receivedAt":"2025-11-25T01:27:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I was surprised that a single \"-c foo\" argument would work, but it makes\n> sense: it is the \"stuck\" form of the short option \"-c\". So:\n>\n> git cmd -cfoo\n>\n> should be the equivalent of:\n>\n> git cmd -c foo\n>\n> whenever \"-c\" takes an option. It is just surprising to read because of\n> the leading space in the value.\n\nAhh, OK, so\n\n\tgit cmd '-c foo.bar=baz'\n\nwas doing\n\n\tgit cmd --config=' foo.bar=baz'\n\nor an easier-to-read form to express in the \"stuck\" form of the\nshort option\n\n\tgit cmd -c' foo.bar=baz'\n\nwhich I totally missed. I agree that the option parser is doing the\nright thing for that case, including passing \" foo=bar\" with a\nleading space as its value.\n\n> So yes, we did allow that until recently, along with:\n>\n> git clone -c ' foo.bar = baz'\n>\n> which keeps the space in the value \"baz\", but otherwise sets foo.bar.\n>\n> I agree it was certainly surprising. Despite the real-world report that\n> started this thread, it is oddball enough that I do not think we want to\n> continue supporting it even for historical reasons. It is not quite at\n> the level of https://xkcd.com/1172/, but especially the form that the OP\n> showed looks like a mistaken invocation that happened to work (and would\n> not work for any other option in general).\n\nAfter you explained the \"that's stuck form with leading whitespace\nin the value\" I missed, I wasn't so sure. \"The value is supposed to\nbe a configuration variable, followed by an equal sign, followed by\nits value; what good does it do if we retained the leading\nwhitespace---stripping is a usability feature\" would work as an\nargument in this particular case, even though it may not work in\ngeneral. Of course, the right thing to do when \"git clone -c\"\noption was introduced would have been to notice that the stripping\nof spaces is unwelcome complication of the UI and reject/correct it,\nbut it is way too late for that now.\n\nThe right right thing to do at this point may be to fix the\nregression and at the same time mark the \"feature\" as deprecated,\nand remove it following the usual deprecation procedure, but that\ncertainly sounds like an unnecessary waste of engineering effort.\n\nSo, I dunno.\n"},{"id":"531276","messageId":"bb7791ea-cfdb-842e-c079-b62b0f183fe1@gmx.de","threadId":"64524","inReplyTo":"CALnO6CBJppT3ELyu54rJvP+uqcMomJS9Nr_JTgfssn8iqG7MWA@mail.gmail.com","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-11-25T20:16:13Z","receivedAt":"2025-11-25T20:16:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ran & Ben,\n\nOn Mon, 24 Nov 2025, D. Ben Knoble wrote:\n\n> On Mon, Nov 24, 2025 at 12:23 AM Ran Ari-Gur wrote:\n> >\n> > There's a small regression in Git v2.52.0; it used to be that a command of the\n> > form\n> >\n> > git clone '-c KEY=VALUE' ...\n> >\n> > or\n> >\n> > git clone '--config= KEY=VALUE' ...\n> >\n> > would trim whitespace around KEY, making the command equivalent to this:\n> >\n> > git clone --config=KEY=VALUE ...\n> >\n> > The relevant code was here:\n> > https://github.com/git/git/blob/v2.51.2/config.c#L649\n> >\n> > That functionality was removed in this refactoring commit:\n> > https://github.com/git/git/commit/dcecac2580ef871186fdc4e9efc87815a4ce4c66\n> >\n> > As a result, a command like the above will now fail, with an error such as this:\n> >\n> > error: invalid key: advice.detachedHead=false\n> > fatal: unable to write parameters to config file\n> >\n> > because config keys are not allowed to contain whitespace.\n> >\n> > I believe this change was unintentional; it was not mentioned in the commit\n> > message or the release notes.\n> >\n> > This probably isn't a common case, and the project where I ran into this issue\n> > has already fixed it on their end (they now pass -c and KEY=VALUE as separate\n> > arguments); but since Git aims to ensure backward-compatibility where possible,\n> > I figured I should report it.\n\nThis has also been reported in\nhttps://github.com/git-for-windows/git/issues/5972 as breaking Git LFS.\n\n> Thanks! As far as backward compatibility, I think this behavior has\n> been around since 2010's 8b1fa77867 (Allow passing of configuration\n> parameters in the command line, 2010-03-26) which morphed via\n> 572e4f6a0c (Use strbufs instead of open-coded string manipulation,\n> 2010-03-26) into the strbuf_trim(pair[0]) that you pointed to as\n> disappearing.\n> \n> Interestingly, I note that we dropped the trim around pair[1] in\n> 06eb708f33 (config: always parse GIT_CONFIG_PARAMETERS during\n> git_config, 2011-05-24), but I don't see that discussed in the commit\n> message either. I tried a handful of mailing list searches around\n> 20110524224955.GC24527@sigill.intra.peff.net, but didn't find any\n> relevant discussion (though my lore-search skills are mediocre).\n\nI am awfully pinched on time right now, but I _think_ that this could be\nthe start of a fix:\n\n-- snipsnap --\ndiff --git a/config.c b/config.c\nindex f1def0dcfba..2b2efe479dc 100644\n--- a/config.c\n+++ b/config.c\n@@ -637,7 +637,7 @@ int git_config_parse_parameter(const char *text,\n \n \tkvi_from_param(&kvi);\n \n-\tstring_list_split(&pair, text, \"=\", 1);\n+\tstring_list_split_f(&pair, text, \"=\", 1, STRING_LIST_SPLIT_TRIM_FIRST);\n \tif (!pair.nr)\n \t\treturn error(_(\"bogus config parameter: %s\"), text);\n \ndiff --git a/string-list.c b/string-list.c\nindex 08dc00984cc..9b5f1d71a9d 100644\n--- a/string-list.c\n+++ b/string-list.c\n@@ -326,6 +326,13 @@ static int split_string(struct string_list *list, const char *string, const char\n \telse if (!in_place && !list->strdup_strings)\n \t\tBUG(\"string_list_split() called without strdup_strings\");\n \n+\tif (flags & STRING_LIST_SPLIT_TRIM_FIRST) {\n+\t\tif (flags & STRING_LIST_SPLIT_TRIM)\n+\t\t\tflags &= ~STRING_LIST_SPLIT_TRIM_FIRST;\n+\t\telse\n+\t\t\tflags |= STRING_LIST_SPLIT_TRIM;\n+\t}\n+\n \tfor (;;) {\n \t\tchar *end;\n \n@@ -345,6 +352,9 @@ static int split_string(struct string_list *list, const char *string, const char\n \t\tif (!end)\n \t\t\treturn count;\n \t\tp = end + 1;\n+\n+\t\tif (flags & STRING_LIST_SPLIT_TRIM_FIRST)\n+\t\t\tflags &= ~STRING_LIST_SPLIT_TRIM;\n \t}\n }\n \ndiff --git a/string-list.h b/string-list.h\nindex fa6ba07853c..938707bf09a 100644\n--- a/string-list.h\n+++ b/string-list.h\n@@ -297,6 +297,8 @@ enum {\n \tSTRING_LIST_SPLIT_TRIM = (1 << 0),\n \t/* omit adding empty string piece to the resulting list */\n \tSTRING_LIST_SPLIT_NONEMPTY = (1 << 1),\n+\t/* trim only the first */\n+\tSTRING_LIST_SPLIT_TRIM_FIRST = (1 << 2),\n };\n \n int string_list_split_f(struct string_list *, const char *string,\n"},{"id":"531277","messageId":"xmqq8qftrcqb.fsf@gitster.g","threadId":"64524","inReplyTo":"xmqqo6oqucka.fsf@gitster.g","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-25T22:03:56Z","receivedAt":"2025-11-25T22:03:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The right right thing to do at this point may be to fix the\n> regression and at the same time mark the \"feature\" as deprecated,\n> and remove it following the usual deprecation procedure, but that\n> certainly sounds like an unnecessary waste of engineering effort.\n>\n> So, I dunno.\n\n\nThe first step of the \"right right thing\" may look something like\nthis. As this thread analyzed so far, this awkward lenience exists\nonly in \"clone -c =\" in that the keyname is trimmed, so\nisolating the damage within the clone's code path would be the right\napproach, if we want to keep this awkward lenience alive a little\nbit longer.\n\nThis function receives the string_list that accumulated\nthe \"-c\" and \"--config \" command line parameters\n(plus some internally generated ones related to submodules) and\nfeeds them one at a time to git_config_parse_parameter() that\nexpects the = pair to be fed.\n\n\n builtin/clone.c | 21 ++++++++++++++++++++-\n 1 file changed, 20 insertions(+), 1 deletion(-)\n\ndiff --git c/builtin/clone.c w/builtin/clone.c\nindex c990f398ef..4ea8c92a6b 100644\n--- c/builtin/clone.c\n+++ w/builtin/clone.c\n@@ -779,7 +779,26 @@ static void write_config(struct string_list *config)\n \tint i;\n \n \tfor (i = 0; i < config->nr; i++) {\n-\t\tif (git_config_parse_parameter(config->items[i].string,\n+\t\t/*\n+\t\t * NEEDSWORK: a backward compatibility wart that made\n+\t\t * us tolerate (note the leading whitespace before\n+\t\t * the variable name)\n+\t\t *\n+\t\t * $ git clone '-c foo.bar=baz'\n+\t\t *\n+\t\t * and treated as if the leading whitespace before the\n+\t\t * variable name did not exist. Apparently a third\n+\t\t * party tool \"Bamboo\" relies on this past stupidity\n+\t\t * of ours.\n+\t\t *\n+\t\t * Eventually we should deprecate and remove this.\n+\t\t */\n+\t\tconst char *trimleft = config->items[i].string;\n+\n+\t\twhile (*trimleft && isspace(*trimleft))\n+\t\t\ttrimleft++;\n+\n+\t\tif (git_config_parse_parameter(trimleft,\n \t\t\t\t\t write_one_config, NULL) < 0)\n \t\t\tdie(_(\"unable to write parameters to config file\"));\n \t}\n"},{"id":"531301","messageId":"20251126145320.GA4143292@coredump.intra.peff.net","threadId":"64524","inReplyTo":"xmqqo6oqucka.fsf@gitster.g","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-11-26T14:53:20Z","receivedAt":"2025-11-26T14:53:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 24, 2025 at 05:27:01PM -0800, Junio C Hamano wrote:\n\n> > So yes, we did allow that until recently, along with:\n> >\n> > git clone -c ' foo.bar = baz'\n> >\n> > which keeps the space in the value \"baz\", but otherwise sets foo.bar.\n> >\n> > I agree it was certainly surprising. Despite the real-world report that\n> > started this thread, it is oddball enough that I do not think we want to\n> > continue supporting it even for historical reasons. It is not quite at\n> > the level of https://xkcd.com/1172/, but especially the form that the OP\n> > showed looks like a mistaken invocation that happened to work (and would\n> > not work for any other option in general).\n> \n> After you explained the \"that's stuck form with leading whitespace\n> in the value\" I missed, I wasn't so sure. \"The value is supposed to\n> be a configuration variable, followed by an equal sign, followed by\n> its value; what good does it do if we retained the leading\n> whitespace---stripping is a usability feature\" would work as an\n> argument in this particular case, even though it may not work in\n> general. Of course, the right thing to do when \"git clone -c\"\n> option was introduced would have been to notice that the stripping\n> of spaces is unwelcome complication of the UI and reject/correct it,\n> but it is way too late for that now.\n> \n> The right right thing to do at this point may be to fix the\n> regression and at the same time mark the \"feature\" as deprecated,\n> and remove it following the usual deprecation procedure, but that\n> certainly sounds like an unnecessary waste of engineering effort.\n\nI agree that is the most conservative choice, but I'd also be\ncomfortable just calling this a bug that was fixed. The leading space\nwas accepted only by \"git clone -c\" and not \"git -c\". And of course\nthere is almost no other option in all of Git where doing \"-o foo\" as a\nsingle argument would do the right thing[1].\n\nI would be more sympathetic if the original report was \"it is useful for\nso-and-so reason to do this whitespace stripping\". But it really sounds\nlike the problem was some caller doing something like (in perl\npseudo-code):\n\n system(\"git\", \"clone\", \"-c $key\", $repo);\n\ninstead of:\n\n system(\"git\", \"clone\", \"-c\", $key, $repo);\n\nwhich is just a bug that happened to work in this limited instance.\n\nSo my inclination would be to leave it be, because I do not think it\nmerits the time. But if somebody else wants to go for it, I will not\nstop them. ;)\n\n-Peff\n\n[1] Given our recent discussion of strtol(), I actually wonder if \"-x\n 10\" works for \"-x\" that takes a numeric option (because strtol would\n suck up the leading whitespace). So maybe this kind of error is\n silently lurking in more places.\n"},{"id":"531302","messageId":"20251126150215.GB4143292@coredump.intra.peff.net","threadId":"64524","inReplyTo":"xmqq8qftrcqb.fsf@gitster.g","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-11-26T15:02:15Z","receivedAt":"2025-11-26T15:02:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 25, 2025 at 02:03:56PM -0800, Junio C Hamano wrote:\n\n> The first step of the \"right right thing\" may look something like\n> this. As this thread analyzed so far, this awkward lenience exists\n> only in \"clone -c =\" in that the keyname is trimmed, so\n> isolating the damage within the clone's code path would be the right\n> approach, if we want to keep this awkward lenience alive a little\n> bit longer.\n\nThat's not entirely true. It is in any code that calls\ngit_config_parse_parameter(), which includes the old-style parser for\nGIT_CONFIG_PARAMETERS.\n\nSo:\n\n $ GIT_CONFIG_PARAMETERS=\"' foo.bar =baz'\" git.v2.51.0 config foo.bar\n baz\n\n $ GIT_CONFIG_PARAMETERS=\"' foo.bar =baz'\" git.v2.52.0 config foo.bar\n error: invalid key: foo.bar\n fatal: unable to parse command-line config\n\nThat doesn't trigger via \"git -c\", because we use the \"new\" form these\ndays (so it started rejecting the extra whitespace in 2021). And you'd\nonly see it if you hand-crafted the variable, or an old version of Git\nset parameters that were then parsed by a newer one.\n\nSo whether that is a case we care about is up for debate. But if we are\ngoing to accommodate backwards compatibility, we have to decide where to\ndraw the line.\n\n> diff --git c/builtin/clone.c w/builtin/clone.c\n> index c990f398ef..4ea8c92a6b 100644\n> --- c/builtin/clone.c\n> +++ w/builtin/clone.c\n> @@ -779,7 +779,26 @@ static void write_config(struct string_list *config)\n> \tint i;\n> \n> \tfor (i = 0; i < config->nr; i++) {\n> -\t\tif (git_config_parse_parameter(config->items[i].string,\n> +\t\t/*\n> +\t\t * NEEDSWORK: a backward compatibility wart that made\n> +\t\t * us tolerate (note the leading whitespace before\n> +\t\t * the variable name)\n> +\t\t *\n> +\t\t * $ git clone '-c foo.bar=baz'\n> +\t\t *\n> +\t\t * and treated as if the leading whitespace before the\n> +\t\t * variable name did not exist. Apparently a third\n> +\t\t * party tool \"Bamboo\" relies on this past stupidity\n> +\t\t * of ours.\n> +\t\t *\n> +\t\t * Eventually we should deprecate and remove this.\n> +\t\t */\n> +\t\tconst char *trimleft = config->items[i].string;\n> +\n> +\t\twhile (*trimleft && isspace(*trimleft))\n> +\t\t\ttrimleft++;\n\nThe old code actually trimmed both sides. So:\n\n $ GIT_CONFIG_PARAMETERS=\"'foo.bar =baz'\" git.v2.51.0 config foo.bar\n baz\n\n $ GIT_CONFIG_PARAMETERS=\"'foo.bar =baz'\" git.v2.52.0 config foo.bar\n error: invalid key: foo.bar\n fatal: unable to parse command-line config\n\nAnd I think the latter would still fail with your patch. Again, that\nmight not matter to us, if all we care about is making:\n\n git clone '-c foo.bar=baz' ...\n\nwork as before. But I'm still skeptical that is worthwhile (especially\ngiven that nobody noticed the same change to \"git -c\" a few years ago).\n\n-Peff\n"},{"id":"531313","messageId":"xmqqtsygoh96.fsf@gitster.g","threadId":"64524","inReplyTo":"20251126150215.GB4143292@coredump.intra.peff.net","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-26T17:06:45Z","receivedAt":"2025-11-26T17:06:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> That doesn't trigger via \"git -c\", because we use the \"new\" form these\n> days (so it started rejecting the extra whitespace in 2021). And you'd\n> only see it if you hand-crafted the variable, or an old version of Git\n> set parameters that were then parsed by a newer one.\n>\n> So whether that is a case we care about is up for debate. But if we are\n> going to accommodate backwards compatibility, we have to decide where to\n> draw the line.\n\nI was hoping we already drew the line above the \"clone\" thing ;-)\n\n> The old code actually trimmed both sides. So:\n>\n> $ GIT_CONFIG_PARAMETERS=\"'foo.bar =baz'\" git.v2.51.0 config foo.bar\n> baz\n>\n> $ GIT_CONFIG_PARAMETERS=\"'foo.bar =baz'\" git.v2.52.0 config foo.bar\n> error: invalid key: foo.bar\n> fatal: unable to parse command-line config\n>\n> And I think the latter would still fail with your patch. Again, that\n> might not matter to us, if all we care about is making:\n>\n> git clone '-c foo.bar=baz' ...\n>\n> work as before. But I'm still skeptical that is worthwhile (especially\n> given that nobody noticed the same change to \"git -c\" a few years ago).\n\nTrue.\n\nI do not think I can convince myself to care about this deeply\nenough.\n\nThanks.\n"},{"id":"531314","messageId":"xmqqpl94oh67.fsf@gitster.g","threadId":"64524","inReplyTo":"20251126145320.GA4143292@coredump.intra.peff.net","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-26T17:08:32Z","receivedAt":"2025-11-26T17:08:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I would be more sympathetic if the original report was \"it is useful for\n> so-and-so reason to do this whitespace stripping\". But it really sounds\n> like the problem was some caller doing something like (in perl\n> pseudo-code):\n>\n> system(\"git\", \"clone\", \"-c $key\", $repo);\n>\n> instead of:\n>\n> system(\"git\", \"clone\", \"-c\", $key, $repo);\n>\n> which is just a bug that happened to work in this limited instance.\n>\n> So my inclination would be to leave it be, because I do not think it\n> merits the time. But if somebody else wants to go for it, I will not\n> stop them. ;)\n\n;-) I might, as it would consume my time as well as theirs.\n"},{"id":"531469","messageId":"20251130134930.GB199421@coredump.intra.peff.net","threadId":"64524","inReplyTo":"xmqqtsygoh96.fsf@gitster.g","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-11-30T13:49:30Z","receivedAt":"2025-11-30T13:49:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 26, 2025 at 09:06:45AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > That doesn't trigger via \"git -c\", because we use the \"new\" form these\n> > days (so it started rejecting the extra whitespace in 2021). And you'd\n> > only see it if you hand-crafted the variable, or an old version of Git\n> > set parameters that were then parsed by a newer one.\n> >\n> > So whether that is a case we care about is up for debate. But if we are\n> > going to accommodate backwards compatibility, we have to decide where to\n> > draw the line.\n> \n> I was hoping we already drew the line above the \"clone\" thing ;-)\n\nOK. :) I am OK with that, but I wanted to make sure we were doing it\nconsciously.\n\n> > And I think the latter would still fail with your patch. Again, that\n> > might not matter to us, if all we care about is making:\n> >\n> > git clone '-c foo.bar=baz' ...\n> >\n> > work as before. But I'm still skeptical that is worthwhile (especially\n> > given that nobody noticed the same change to \"git -c\" a few years ago).\n> \n> True.\n> \n> I do not think I can convince myself to care about this deeply\n> enough.\n\nThat's about where I'm at, though I'm a little worried by Dscho's\nmention that apparently git-lfs has the same problem. So maybe it's more\nwidespread than I am giving it credit for?\n\nIf we draw the line at \"-c foo=bar\" as a single argument (which is what\nit sounds like git-lfs is doing, too) then your simple \"trim\" patch\nwould be enough.\n\nI dunno. I certainly do not want to get into a deprecation period and\nall of that mess. Maybe the breakage in v2.52.0 would be enough for\ncallers to notice and fix their invocations, and we could just quietly\nremove the hack later? But then, I am not sure what makes \"later\" any\nbetter than \"now\".\n\n-Peff\n"},{"id":"531472","messageId":"xmqqzf83bdc5.fsf@gitster.g","threadId":"64524","inReplyTo":"20251130134930.GB199421@coredump.intra.peff.net","subject":"Re: [BUG] `git clone '-c KEY=VALUE'` no longer works","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-30T18:11:06Z","receivedAt":"2025-11-30T18:11:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> That's about where I'm at, though I'm a little worried by Dscho's\n> mention that apparently git-lfs has the same problem. So maybe it's more\n> widespread than I am giving it credit for?\n\nReading , I\nthink the mention of LFS in Dscho's message on this list was a\nred-herring, as corrected by Dscho himself at\n\n https://github.com/git-for-windows/git/issues/5972#issuecomment-3577520017\n\nI do not know if buggily constructed command line by Atlassian\nBamboo is something we want to bend over backwards to help papering\nover, but probably not.\n\n> I dunno. I certainly do not want to get into a deprecation period and\n> all of that mess. Maybe the breakage in v2.52.0 would be enough for\n> callers to notice and fix their invocations, and we could just quietly\n> remove the hack later? But then, I am not sure what makes \"later\" any\n> better than \"now\".\n\nYes. Let's write it off as an inadvertent bugfix ;-)\n\nThanks.\n"}]}