{"thread":{"id":"53323","subject":"[PATCH] config: use GIT_CONFIG in git config sequence","startedAt":"2020-04-25T23:57:59Z","lastAt":"2020-04-27T20:04:18Z","messageCount":14,"participants":["Mateusz Nowotyński","Junio C Hamano","Matt Rogers","Philip Oakley","brian m. carlson","Mateusz Nowotynski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"396272","messageId":"20200425235716.1822560-1-maxmati4@gmail.com","threadId":"53323","inReplyTo":null,"subject":"[PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Mateusz Nowotyński","fromEmail":"maxmati4@gmail.com","sentAt":"2020-04-25T23:57:16Z","receivedAt":"2020-04-25T23:57:59Z","isPatch":true,"sender":{"key":"maxmati4@gmail.com","avatar":null},"body":"Currently, there is no way to use config file other then ~/.gitconfig.\nThis can cause a problem, for example, when running tests of software that\ndepends on git. In such a case user's gitconfig may contain settings that\nare incompatible with tests.\n\nThis commit expands existing GIT_CONFIG environment variable, that is\ncurrently used only by git config, that it is used also in other commands.\nWhen it is set it's the only config file that's being used.\n\nSigned-off-by: Mateusz Nowotyński <maxmati4@gmail.com>\n---\n Documentation/git.txt |  4 ++++\n config.c              |  3 +++\n t/t0007-git-var.sh    | 20 ++++++++++++++++++++\n 3 files changed, 27 insertions(+)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 9d6769e95a..c92411b8d9 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -882,6 +882,10 @@ standard output.\n \tadequate and support for it is likely to be removed in the\n \tforeseeable future (along with the variable).\n \n+GIT_CONFIG::\n+\tTake the configuration from the given file instead of using typical\n+\tresolve mechanism.\n+\n Discussion[[Discussion]]\n ------------------------\n \ndiff --git a/config.c b/config.c\nindex d17d2bd9dc..811b4e2186 100644\n--- a/config.c\n+++ b/config.c\n@@ -1754,6 +1754,7 @@ int config_with_options(config_fn_t fn, void *data,\n \t\t\tconst struct config_options *opts)\n {\n \tstruct config_include_data inc = CONFIG_INCLUDE_INIT;\n+\tconst char* env_config = getenv(CONFIG_ENVIRONMENT);\n \n \tif (opts->respect_includes) {\n \t\tinc.fn = fn;\n@@ -1776,6 +1777,8 @@ int config_with_options(config_fn_t fn, void *data,\n \t\treturn git_config_from_file(fn, config_source->file, data);\n \telse if (config_source && config_source->blob)\n \t\treturn git_config_from_blob_ref(fn, config_source->blob, data);\n+\telse if (env_config)\n+\t\treturn git_config_from_file(fn, env_config, data);\n \n \treturn do_git_config_sequence(opts, fn, data);\n }\ndiff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh\nindex 1f600e2cae..74ed80f5ca 100755\n--- a/t/t0007-git-var.sh\n+++ b/t/t0007-git-var.sh\n@@ -46,4 +46,24 @@ test_expect_success 'listing and asking for variables are exclusive' '\n \ttest_must_fail git var -l GIT_COMMITTER_IDENT\n '\n \n+\n+cat > config_file << EOF\n+[ein]\n+\tbahn = strasse\n+EOF\n+\n+test_expect_success 'respect GIT_CONFIG' '\n+\tGIT_CONFIG=$(pwd)/config_file git var -l >actual &&\n+\techo strasse >expect &&\n+\tsed -n s/ein\\\\.bahn=//p <actual >actual.bahn &&\n+\ttest_cmp expect actual.bahn\n+'\n+\n+test_expect_success 'GIT_CONFIG leads to not existsing file' '\n+\ttest_when_finished \"sane_unset GIT_CONFIG\" &&\n+\tGIT_CONFIG=$(pwd)/not_existsing_config_file &&\n+\texport GIT_CONFIG &&\n+\ttest_must_fail git var -l\n+'\n+\n test_done\n-- \n2.24.1\n\n"},{"id":"396273","messageId":"xmqq5zdn9k3r.fsf@gitster.c.googlers.com","threadId":"53323","inReplyTo":"20200425235716.1822560-1-maxmati4@gmail.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-26T00:16:56Z","receivedAt":"2020-04-26T00:17:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mateusz Nowotyński <maxmati4@gmail.com> writes:\n\n> Currently, there is no way to use config file other then ~/.gitconfig.\n> This can cause a problem, for example, when running tests of software that\n> depends on git. In such a case user's gitconfig may contain settings that\n> are incompatible with tests.\n\nWhile I can remotely imagine how an environment variable that\noverrides everything might be useful at times, we already use\nGIT_CONFIG environment for a different purpose, so even if such a\nfeature were desirable, the name is already taken, and you'd want to\nhunt for another one.  Also, I do not think I'll take this patch if\nthe justification were solely the above, as it is a solved problem,\ntogether with the use of GIT_CONFIG_NOSYSTEM and GIT_ATTR_NOSYSTEM.\n\nTests of a software that depends on git, and perhaps other things,\nwill be affected in things under the testing user's home directory,\nand not just ~/.gitconfig file.  Providing stable environment to run\nin to your tests is a useful thing to do, but it is not a viable or\na particularly smart strategy for doing so to tweak each and every\nsoftware that your software may depend on, and your software itself,\nwith a custom change like this patch.\n\nYou can prepare a pretend-home directory for the use of your tests\nand point the environment variable $HOME to it while running your\ntests.  See how we do this in our test suite for inspiration---it\nall happens in t/test-lib.sh, I think.\n\nThanks.\n\n\n\n"},{"id":"396280","messageId":"CAOjrSZs33-CqV5m4wKROYJT8au1hup7bGZWiEaXMV7cU4p-J=Q@mail.gmail.com","threadId":"53323","inReplyTo":"20200425235716.1822560-1-maxmati4@gmail.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2020-04-26T01:12:23Z","receivedAt":"2020-04-26T01:12:37Z","isPatch":true,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"This would need an appropriate addition to show-scope functionality in order\nto be considered complete too, as I believe the current code would give it a\nscope of \"unknown\" which is obviously incorrect since we know the scope.\n\n-- \nMatthew Rogers\n"},{"id":"396285","messageId":"383520d8-0623-ecf5-bb02-230a35359a6b@iee.email","threadId":"53323","inReplyTo":"xmqq5zdn9k3r.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-04-26T09:58:34Z","receivedAt":"2020-04-26T09:58:40Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 26/04/2020 01:16, Junio C Hamano wrote:\n> Mateusz Nowotyński <maxmati4@gmail.com> writes:\n>\n>> Currently, there is no way to use config file other then ~/.gitconfig.\n>> This can cause a problem, for example, when running tests of software that\n>> depends on git. In such a case user's gitconfig may contain settings that\n>> are incompatible with tests.\n> While I can remotely imagine how an environment variable that\n> overrides everything might be useful at times, we already use\n> GIT_CONFIG environment for a different purpose, so even if such a\n> feature were desirable, the name is already taken, and you'd want to\n> hunt for another one.  Also, I do not think I'll take this patch if\n> the justification were solely the above, as it is a solved problem,\n> together with the use of GIT_CONFIG_NOSYSTEM and GIT_ATTR_NOSYSTEM.\n\nMateusz: is there a discoverability/documentation issue for these extra\nconfig settings (a better patch maybe there).\nI know in the past (in another context) I had failed to appreciate that\nthese had been set so couldn't work out why some problems were occurring\nfor me when testing some ideas.\n>\n> Tests of a software that depends on git, and perhaps other things,\n> will be affected in things under the testing user's home directory,\n> and not just ~/.gitconfig file.  Providing stable environment to run\n> in to your tests is a useful thing to do, but it is not a viable or\n> a particularly smart strategy for doing so to tweak each and every\n> software that your software may depend on, and your software itself,\n> with a custom change like this patch.\n>\n> You can prepare a pretend-home directory for the use of your tests\n> and point the environment variable $HOME to it while running your\n> tests.  See how we do this in our test suite for inspiration---it\n> all happens in t/test-lib.sh, I think.\n>\n> Thanks.\n>\n--\nPhilip\n"},{"id":"396286","messageId":"ff9a63d4-80e4-8090-c85c-03fd3ab43c55@iee.email","threadId":"53323","inReplyTo":"CAOjrSZs33-CqV5m4wKROYJT8au1hup7bGZWiEaXMV7cU4p-J=Q@mail.gmail.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-04-26T10:00:53Z","receivedAt":"2020-04-26T10:00:58Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Matt,\n\nOn 26/04/2020 02:12, Matt Rogers wrote:\n> This would need an appropriate addition to show-scope functionality in order\n> to be considered complete too, as I believe the current code would give it a\n> scope of \"unknown\" which is obviously incorrect since we know the scope.\n>\nGiven the extra config environment settings, could/should the\n--show-scope (or complementary option) also show/clarify these\nenvironment variable settings?\n--\nPhilip\n"},{"id":"396287","messageId":"CAOjrSZt7WJy1vv97Rw9MFJyTcB2Ehqq9BjGrXMtV95oB5p53SA@mail.gmail.com","threadId":"53323","inReplyTo":"ff9a63d4-80e4-8090-c85c-03fd3ab43c55@iee.email","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2020-04-26T13:30:13Z","receivedAt":"2020-04-26T13:30:28Z","isPatch":true,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"> Given the extra config environment settings, could/should the\n> --show-scope (or complementary option) also show/clarify these\n> environment variable settings?\n\nI'm lukewarm either way on this one, I think it would be pretty trivial\nto write something that did this, so that only leaves the question of\n'should' we do this, which I don't really have any particularly strong\nfeelings about.  What would this even ultimately look like? perhaps\nsomething like this for a command of `git config --show-scope`:\n\nsystem var=option (currently ignored due to GIT_CONFIG_NOSYSTEM)\n\nWhich kind of begs the question of how many people set that variable\nand then forget that they set it?  Although I can totally see why it would\nbe nice to have some kind of config flag that's a big\n\"Just show me everything that's going on option\" which considering these\nvariables would probably be a little bit more than the current next-best of\n`git config --list --show-scope --show-origin`.  Again though, I'm not\nexactly sure how useful such an option would be.\n\n-- \nMatthew Rogers\n"},{"id":"396297","messageId":"5c1005a7-273e-fab0-0d0d-78bd0d3d13f6@gmail.com","threadId":"53323","inReplyTo":"xmqq5zdn9k3r.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Mateusz Nowotyński","fromEmail":"maxmati4@gmail.com","sentAt":"2020-04-26T19:32:05Z","receivedAt":"2020-04-26T19:32:27Z","isPatch":true,"sender":{"key":"maxmati4@gmail.com","avatar":null},"body":"On Sat, Apr 25, 2020 at 05:16:56PM -0700, Junio C Hamano wrote:\n\n\n> Mateusz Nowotyński <maxmati4@gmail.com> writes:\n\n\n>\n\n\n> > Currently, there is no way to use config file other then\n~/.gitconfig.\n\n> > This can cause a problem, for example, when running tests of\nsoftware that\n\n> > depends on git. In such a case user's gitconfig may contain settings\nthat\n\n> > are incompatible with tests.\n\n\n>\n\n\n> While I can remotely imagine how an environment variable that\n\n\n> overrides everything might be useful at times, we already use\n\n\n> GIT_CONFIG environment for a different purpose, so even if such a\n\n\n> feature were desirable, the name is already taken, and you'd want to\n\n\n> hunt for another one.  Also, I do not think I'll take this patch if\n\n\n> the justification were solely the above, as it is a solved problem,\n\n\n> together with the use of GIT_CONFIG_NOSYSTEM and GIT_ATTR_NOSYSTEM.\n\n\nAgreed that we shouldn't reuse GIT_CONFIG but as you said, before huntig\n\n\nfor new name we should decide if we want this at all. As far as I know\n\n\nGIT_CONFIG_NOSYSTEM only allows to ignore system wide config file stored\n\n\nin /etc not one in the user home directory (~/.gitconfig). Is there any\nway\n\nto achive it that I'm not aware of (other then overwriting HOME\nvariable)?\n\nOr maybe you would like more to add something like GIT_CONFIG_NOUSER to\n\n\njust ignore this file?\n\n\n>\n\n\n> Tests of a software that depends on git, and perhaps other things,\n\n\n> will be affected in things under the testing user's home directory,\n\n\n> and not just ~/.gitconfig file.  Providing stable environment to run\n\n\n> in to your tests is a useful thing to do, but it is not a viable or\n\n\n> a particularly smart strategy for doing so to tweak each and every\n\n\n> software that your software may depend on, and your software itself,\n\n\n> with a custom change like this patch.\n\n\nProblem that we are facing is that if developer has git configured to\n\n\nsign commits using, for example, yubikey he has to touch it on each\n\n\ncommit that makes tests unusable.\n\n\n> You can prepare a pretend-home directory for the use of your tests\n\n\n> and point the environment variable $HOME to it while running your\n\n\n> tests.  See how we do this in our test suite for inspiration---it\n\n\n> all happens in t/test-lib.sh, I think.\n\n\n>\n\n\nThis is what we do currently but the problem with this solution is that\n\n\nit breaks other software that also uses HOME as base path for their\n\n\ndata. For example asdf version manager.\n\n\n> Thanks.\n\n\n>\n\n\nRegards,\n\n\nMateusz\n"},{"id":"396300","messageId":"8992c1a7-a638-e823-1cb7-2c8f6b28d486@iee.email","threadId":"53323","inReplyTo":"CAOjrSZt7WJy1vv97Rw9MFJyTcB2Ehqq9BjGrXMtV95oB5p53SA@mail.gmail.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-04-26T20:04:50Z","receivedAt":"2020-04-26T20:04:55Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Matt,\n\nOn 26/04/2020 14:30, Matt Rogers wrote:\n>> Given the extra config environment settings, could/should the\n>> --show-scope (or complementary option) also show/clarify these\n>> environment variable settings?\n> I'm lukewarm either way on this one, I think it would be pretty trivial\n> to write something that did this, so that only leaves the question of\n> 'should' we do this, which I don't really have any particularly strong\n> feelings about.  \nMy thought was that in some cases folks will feel they 'know' where\ntheir system and global configs are located, but that 'git config'\ncommand isn't showing them those contents.\n\n> What would this even ultimately look like? perhaps\n> something like this for a command of `git config --show-scope`:\n>\n> system var=option (currently ignored due to GIT_CONFIG_NOSYSTEM)\nThat's one option.\n\nThe other, non-programmatic way, it to mention the environment variable\nin the 'git config' man page, at the --show-scope section, telling folk\nthat if those env variables are set there won't be any scope to show!\n>\n> Which kind of begs the question of how many people set that variable\n> and then forget that they set it?  \n\nThe one that caught me was the test suit[1]. I was unable to replicate\nresults when I set up a test. This can be bad on Windows where some\nsettings need to be auto set (or are commonly set) and maybe result in\nconflicts. Often what doesn't know what's been done on ones behalf.\nThere's plenty of spare configs to go round ;-)\n\n> Although I can totally see why it would\n> be nice to have some kind of config flag that's a big\n> \"Just show me everything that's going on option\" which considering these\n> variables would probably be a little bit more than the current next-best of\n> `git config --list --show-scope --show-origin`.  Again though, I'm not\n> exactly sure how useful such an option would be.\n\nMateusz's original problem was with discovery of these env variables, so\nended up with an XY-problem of proposing a patch to redirect the\n~/.gitconfig file, because relevant the env variables weren't (for him,\nand previously myself) discoverable.\n\nIf we go with a 'No one reads the manuals' developer view, then the\nsolution has to be more code... hence my wondering if there was an easy\nwin inside the code, or if it needs to be a subjective update to the man\npages (never 'easy').\n\n\nThe man page\nThe GIT_CONFIG_NOSYSTEM only gets its 1 mention as a heading, while\nGIT_CONFIG  has two (+ a heading). Maybe we need to spread the love for\nNOSYSTEM...\n>\n-- \nPhilip\n\n[1]\nhttps://lore.kernel.org/git/8850d755-07ce-d8d2-6e5c-88393fce34de@iee.org/\n"},{"id":"396301","messageId":"20200426200845.GE6421@camp.crustytoothpaste.net","threadId":"53323","inReplyTo":"5c1005a7-273e-fab0-0d0d-78bd0d3d13f6@gmail.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-04-26T20:08:45Z","receivedAt":"2020-04-26T20:08:52Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-04-26 at 19:32:05, Mateusz Nowotyński wrote:\n> On Sat, Apr 25, 2020 at 05:16:56PM -0700, Junio C Hamano wrote:\n> > You can prepare a pretend-home directory for the use of your tests\n> > and point the environment variable $HOME to it while running your\n> > tests.  See how we do this in our test suite for inspiration---it\n> > all happens in t/test-lib.sh, I think.\n> \n> This is what we do currently but the problem with this solution is that\n> it breaks other software that also uses HOME as base path for their\n> data. For example asdf version manager.\n\nI know nothing about the asdf version manager, but if you're relying on\nit for programs, those programs should end up in PATH, and when invoked\nappropriately in those locations, those programs should just work,\nregardless of what $HOME is set to.  If they don't, that would be a\ndefect in asdf, since the Unix expectation is that programs in $PATH\nshould generally function without regard to the setting of $HOME.  From\nmy cursory poking around at the repo, it looks like it should do this\njust fine.\n\nSo you can set $HOME to a temporary directory and still use asdf as long\nas your don't reset $PATH.  Or, if you want to specifically load asdf\nprograms first, you could do something like this:\n\n  #!/bin/sh\n\n  . \"$HOME/asdf/asdf.sh\"\n  export HOME=$(mktemp -d)\n  # Run tests here.\n\nRegardless of your tooling, you definitely want to reset $HOME in almost\nevery nontrivial shell testsuite, since many users have configuration\nfiles or data storage that you wouldn't want to use.  For example, if\nyou generate a new GnuPG key on every run, the user won't appreciate it\nif you import it as one of their private keys.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"396303","messageId":"xmqq1roa9d1f.fsf@gitster.c.googlers.com","threadId":"53323","inReplyTo":"5c1005a7-273e-fab0-0d0d-78bd0d3d13f6@gmail.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-26T21:01:48Z","receivedAt":"2020-04-26T21:01:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mateusz Nowotyński <maxmati4@gmail.com> writes:\n\n[jc: I do not know why your reply had two blank lines for every\nline, but I reformatted them to make them repliable]\n\n> This is what we do currently but the problem with this solution is that\n> it breaks other software that also uses HOME as base path for their\n> data. For example asdf version manager.\n\nThat sounds like another reason why you would want to redirect HOME\nto a stable and known directory constructed specifically for the use\nof your tests.  Just like you do not want the behaviour of the\ntested program getting affected by random settings the users, who\nare running your tests, might have in their $HOME/.gitconfig, random\nsettings for \"asdf version manager\" (whatever it is) the users\nhappen to have in their $HOME directory would also have undesirable\nside effects to your tests, no?\n\n\n"},{"id":"396304","messageId":"xmqqwo627xsd.fsf@gitster.c.googlers.com","threadId":"53323","inReplyTo":"8992c1a7-a638-e823-1cb7-2c8f6b28d486@iee.email","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-26T21:16:34Z","receivedAt":"2020-04-26T21:16:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley <philipoakley@iee.email> writes:\n\n> Mateusz's original problem was with discovery of these env variables,...\n\nI somehow doubt it.  \n\nCertainly, defeating /etc/gitconfig should be a part of the solution\nto the \"I want a stable environment to run tests reproducibly,\nwithout getting affected by random settings the testing user may get\naffected\" problem.  It is not enough to defeat $HOME/.gitconfig (and\nits xdg variant).\n\nBut I didn't get the feeling that Mateusz was even aware of the need\nto defeat the system wide configuration; Mateusz only mentioned and\ncared about $HOME/.gitconfig (and its xdg variant).\n\nAnd the thing is that we do have support for an environment variable\nto defeat the system-wide configuration (GIT_CONFIG_NOSYSTEM), but\ndiscovering it would not have been sufficient to solve the \"stable\nenvironment for reproducible tests\" problem, as we do not have an\nenvironment variable to defeat the global (i.e. per user) one.\n\nSo, I do not think the problem was with discovery at all.  The\nproblem was two levels deep, (1) not realizing the need to defeat\nthe system wide settings (for which the environment may have been a\ngood solution once the need to solve that problem got recognised),\nand (2) not realizing the need to redirect $HOME for programs other\nthan git, hence omitting $HOME/.gitconfig from the sequence is not\na sufficient solution.\n\nHaving said all that, I addition of GIT_CONFIG_NOGLOBAL (or\nGIT_CONFIG_NOUSER) may not be such a bad thing.  We probably will\nadd GIT_CONFIG_NOLOCAL (or GIT_CONFIG_NOREPOSITORY) to complement\nthese two if that happens.  I dunno.\n\n"},{"id":"396305","messageId":"xmqqsggp98to.fsf@gitster.c.googlers.com","threadId":"53323","inReplyTo":"xmqqwo627xsd.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-26T22:32:51Z","receivedAt":"2020-04-26T22:33:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Philip Oakley <philipoakley@iee.email> writes:\n>\n>> Mateusz's original problem was with discovery of these env variables,...\n>\n> I somehow doubt it.  \n>\n> Certainly, defeating /etc/gitconfig should be a part of the solution\n> to the \"I want a stable environment to run tests reproducibly,\n> without getting affected by random settings the testing user may get\n> affected\" problem.  It is not enough to defeat $HOME/.gitconfig (and\n> its xdg variant).\n>\n> But I didn't get the feeling that Mateusz was even aware of the need\n> ...\n\nAfter re-reading the patch that started this thread, I suspect the\nreason Mateusz did not mention GIT_CONFIG_NOSYSTEM could be because\nhe was aware of the need to defeat /etc/gitconfig, and was already\nusing it.  There was no discovery issue---to somebody who would\npropose the patch under discussion to solve \"I want a stable\nenvironment for testing\", /etc/gitconfig was a solved problem.\n\nAnd unfortunately we do not have GIT_CONFIG_NO_GLOBAL; so there is\nnothing to discover there, either X-<.  If we were to add such an\nenvironment, we need to make sure that it is discoverable ;-)\n\nI still think setting up a directory that can be used as a stable\n$HOME replacement and pointing at it during the test, while\ndeclining the system-wide one with GIT_CONFIG_NOSYSTEM, is the right\napproach for \"stable test environment\" problem.\n"},{"id":"396368","messageId":"20200427193956.GB2223199@leopardus","threadId":"53323","inReplyTo":"xmqqsggp98to.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Mateusz Nowotynski","fromEmail":"maxmati4@gmail.com","sentAt":"2020-04-27T19:39:56Z","receivedAt":"2020-04-27T19:40:01Z","isPatch":true,"sender":{"key":"maxmati4@gmail.com","avatar":null},"body":"On Sun, Apr 26, 2020 at 03:32:51PM -0700, Junio C Hamano wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > Philip Oakley <philipoakley@iee.email> writes:\n> >\n> >> Mateusz's original problem was with discovery of these env variables,...\n> >\n> > I somehow doubt it.  \n> >\n> > Certainly, defeating /etc/gitconfig should be a part of the solution\n> > to the \"I want a stable environment to run tests reproducibly,\n> > without getting affected by random settings the testing user may get\n> > affected\" problem.  It is not enough to defeat $HOME/.gitconfig (and\n> > its xdg variant).\n> >\n> > But I didn't get the feeling that Mateusz was even aware of the need\n> > ...\n> \n> After re-reading the patch that started this thread, I suspect the\n> reason Mateusz did not mention GIT_CONFIG_NOSYSTEM could be because\n> he was aware of the need to defeat /etc/gitconfig, and was already\n> using it.  There was no discovery issue---to somebody who would\n> propose the patch under discussion to solve \"I want a stable\n> environment for testing\", /etc/gitconfig was a solved problem.\nYes, this is exactly the case, I'm fully aware of GIT_CONFIG_NOSYSTEM so\nthere is no problem with system wide config file. Anyway if you want to\nimprove its discoverability I can suggest moving description from\ngit-config to git since it's influences all git commands not only git\nconfig.\n> And unfortunately we do not have GIT_CONFIG_NO_GLOBAL; so there is\n> nothing to discover there, either X-<.  If we were to add such an\n> environment, we need to make sure that it is discoverable ;-)\nI think it will fully solve my problem so if you are willing to accept\nit I can do the implementation, it shouldn't be complex anyway.\nRegarding the discoverability I think the documentation should be put\ntogether with GIT_CONFIG_NOSYSTEM since they are very close to each\nother.\n> I still think setting up a directory that can be used as a stable\n> $HOME replacement and pointing at it during the test, while\n> declining the system-wide one with GIT_CONFIG_NOSYSTEM, is the right\n> approach for \"stable test environment\" problem.\nWe have pretty \"stable test environment\" that is running in CI and it's\nworking really well and stable. Problem starts with developers machines.\nWe would like pose as low requirements on them as possible, ideally it\nwould be just given range of go, ruby and git version that we use. I\nknow that it will be ideal to just overwrite $HOME with some temp\ndirectory but reality is even if it's not fully UNIX compliant there are\ntools that will rely on user $HOME to provide those requirements (go,\nruby and git). I think that in such case it's better to add this small\nfeature to git then go and fix every tool in the world. Currently we\nfound issues only with go cache and mentioned earlier asdf version, but\nI expect more of them as people come and go.\n"},{"id":"396370","messageId":"20200427200412.GC2223199@leopardus","threadId":"53323","inReplyTo":"20200426200845.GE6421@camp.crustytoothpaste.net","subject":"Re: [PATCH] config: use GIT_CONFIG in git config sequence","fromName":"Mateusz Nowotynski","fromEmail":"maxmati4@gmail.com","sentAt":"2020-04-27T20:04:12Z","receivedAt":"2020-04-27T20:04:18Z","isPatch":true,"sender":{"key":"maxmati4@gmail.com","avatar":null},"body":"On Sun, Apr 26, 2020 at 08:08:45PM +0000, brian m. carlson wrote:\n> On 2020-04-26 at 19:32:05, Mateusz Nowotyński wrote:\n> > On Sat, Apr 25, 2020 at 05:16:56PM -0700, Junio C Hamano wrote:\n> > > You can prepare a pretend-home directory for the use of your tests\n> > > and point the environment variable $HOME to it while running your\n> > > tests.  See how we do this in our test suite for inspiration---it\n> > > all happens in t/test-lib.sh, I think.\n> > \n> > This is what we do currently but the problem with this solution is that\n> > it breaks other software that also uses HOME as base path for their\n> > data. For example asdf version manager.\n> \n> I know nothing about the asdf version manager, but if you're relying on\n> it for programs, those programs should end up in PATH, and when invoked\n> appropriately in those locations, those programs should just work,\n> regardless of what $HOME is set to.  If they don't, that would be a\n> defect in asdf, since the Unix expectation is that programs in $PATH\n> should generally function without regard to the setting of $HOME.  From\n> my cursory poking around at the repo, it looks like it should do this\n> just fine.\n> \n> So you can set $HOME to a temporary directory and still use asdf as long\n> as your don't reset $PATH.  Or, if you want to specifically load asdf\n> programs first, you could do something like this:\n> \n>   #!/bin/sh\n> \n>   . \"$HOME/asdf/asdf.sh\"\n>   export HOME=$(mktemp -d)\n>   # Run tests here.\n> \n> Regardless of your tooling, you definitely want to reset $HOME in almost\n> every nontrivial shell testsuite, since many users have configuration\n> files or data storage that you wouldn't want to use.  For example, if\n> you generate a new GnuPG key on every run, the user won't appreciate it\n> if you import it as one of their private keys.\n> -- \n> brian m. carlson: Houston, Texas, US\n> OpenPGP: https://keybase.io/bk2204\n\nTo be honest I also don't know how it exactly works and I personally\ndon't use it. I think it adds to the PATH just thin wrapper not binary \nitself. I guess it's done that way because it looks for .tool-versions \nin current working directory and then fallback to $HOME/.tool-versions.\n\nRegarding reseting HOME we are aware that we cannot do actions that \nhave sideeffects outside test directory so we just won't generate/import\nGnuPG keys.\n\n--\nRegards, Mateusz\n\n"}]}