{"thread":{"id":"62875","subject":"[PATCH 0/3] setup: fix reinit of repos with different formats","startedAt":"2025-01-30T16:24:30Z","lastAt":"2025-02-03T15:02:10Z","messageCount":11,"participants":["Patrick Steinhardt","Junio C Hamano","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"511506","messageId":"20250130-b4-pks-reinit-default-ref-format-v1-0-d2769ca01207@pks.im","threadId":"62875","inReplyTo":null,"subject":"[PATCH 0/3] setup: fix reinit of repos with different formats","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-30T16:24:16Z","receivedAt":"2025-01-30T16:24:30Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nthis issue with the reinitialization of the ref format was recently\ndiscovered in our CI systems at GitLab, where caches contained repos\nwith one ref format but we tried to reinit them with a different ref\nformat. But turns out that the same issue also exists for the object\nformat, so this patch series fixes both issues.\n\nThanks!\n\nPatrick\n\n---\nPatrick Steinhardt (3):\n      t0001: remove duplicate test\n      setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT\n      setup: fix reinit of repos with incompatible GIT_DEFAULT_HASH\n\n setup.c         |  8 ++++++--\n t/t0001-init.sh | 30 +++++++++++++++++++++---------\n 2 files changed, 27 insertions(+), 11 deletions(-)\n\n\n---\nbase-commit: 3b0d05c4a79d0e441283680a864529b02dca5f08\nchange-id: 20250130-b4-pks-reinit-default-ref-format-96a5e2104421\n\n"},{"id":"511507","messageId":"20250130-b4-pks-reinit-default-ref-format-v1-1-d2769ca01207@pks.im","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-0-d2769ca01207@pks.im","subject":"[PATCH 1/3] t0001: remove duplicate test","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-30T16:24:17Z","receivedAt":"2025-01-30T16:24:31Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The test in question is an exact copy of the testcase preceding it.\nRemove it.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n t/t0001-init.sh | 9 ---------\n 1 file changed, 9 deletions(-)\n\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 72a0c2e7d4..213d5984b1 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -861,15 +861,6 @@ test_expect_success 're-init with includeIf.onbranch condition' '\n \ttest_cmp expect actual\n '\n \n-test_expect_success 're-init with includeIf.onbranch condition' '\n-\ttest_when_finished \"rm -rf repo\" &&\n-\tgit init repo &&\n-\tgit -c includeIf.onbranch:nonexistent.path=/does/not/exist init repo &&\n-\techo $GIT_DEFAULT_REF_FORMAT >expect &&\n-\tgit -C repo rev-parse --show-ref-format >actual &&\n-\ttest_cmp expect actual\n-'\n-\n test_expect_success 're-init skips non-matching includeIf.onbranch' '\n \ttest_when_finished \"rm -rf repo config\" &&\n \tcat >config <<-EOF &&\n\n-- \n2.48.1.468.gbf5f394be8.dirty\n\n"},{"id":"511508","messageId":"20250130-b4-pks-reinit-default-ref-format-v1-3-d2769ca01207@pks.im","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-0-d2769ca01207@pks.im","subject":"[PATCH 3/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_HASH","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-30T16:24:19Z","receivedAt":"2025-01-30T16:24:32Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The exact same issue as described in the preceding commit also exists\nfor GIT_DEFAULT_HASH. Thus, reinitializing a repository that e.g. uses\nSHA1 with `GIT_DEFAULT_HASH=sha256 git init` will cause the object\nformat of that repository to change to SHA256. This is of course bogus\nas any existing objects and refs will not be converted, thus causing\nrepository corruption:\n\n    $ git init repo\n    Initialized empty Git repository in /tmp/repo/.git/\n    $ cd repo/\n    $ git commit --allow-empty -m message\n    [main (root-commit) 35a7344] message\n    $ GIT_DEFAULT_HASH=sha256 git init\n    Reinitialized existing Git repository in /tmp/repo/.git/\n    $ git show\n    fatal: your current branch appears to be broken\n\nFix the issue by ignoring the environment variable in case the repo has\nalready been initialized with an object hash.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n setup.c         |  4 +++-\n t/t0001-init.sh | 12 ++++++++++++\n 2 files changed, 15 insertions(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex 53ffeabc5b..7da7aa8984 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -2517,7 +2517,9 @@ static void repository_format_configure(struct repository_format *repo_fmt,\n \t\tint env_algo = hash_algo_by_name(env);\n \t\tif (env_algo == GIT_HASH_UNKNOWN)\n \t\t\tdie(_(\"unknown hash algorithm '%s'\"), env);\n-\t\trepo_fmt->hash_algo = env_algo;\n+\t\tif (repo_fmt->version < 0 ||\n+\t\t    repo_fmt->hash_algo == GIT_HASH_UNKNOWN)\n+\t\t\trepo_fmt->hash_algo = env_algo;\n \t} else if (cfg.hash != GIT_HASH_UNKNOWN) {\n \t\trepo_fmt->hash_algo = cfg.hash;\n \t}\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 6dff8b75f1..c49d9e0d38 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -586,6 +586,18 @@ test_expect_success 'GIT_DEFAULT_HASH overrides init.defaultObjectFormat' '\n \techo sha256 >expected\n '\n \n+for hash in sha1 sha256\n+do\n+\ttest_expect_success \"reinit repository with GIT_DEFAULT_HASH=$hash does not change format\" '\n+\t\ttest_when_finished \"rm -rf repo\" &&\n+\t\tgit init repo &&\n+\t\tgit -C repo rev-parse --show-object-format >expect &&\n+\t\tGIT_DEFAULT_HASH=$hash git init repo &&\n+\t\tgit -C repo rev-parse --show-object-format >actual &&\n+\t\ttest_cmp expect actual\n+\t'\n+done\n+\n test_expect_success 'extensions.objectFormat is not allowed with repo version 0' '\n \ttest_when_finished \"rm -rf explicit-v0\" &&\n \tgit init --object-format=sha256 explicit-v0 &&\n\n-- \n2.48.1.468.gbf5f394be8.dirty\n\n"},{"id":"511509","messageId":"20250130-b4-pks-reinit-default-ref-format-v1-2-d2769ca01207@pks.im","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-0-d2769ca01207@pks.im","subject":"[PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-30T16:24:18Z","receivedAt":"2025-01-30T16:24:32Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"The GIT_DEFAULT_REF_FORMAT environment variable can be set to influence\nthe default ref format that new repostiories shall be initialized with.\nWhile this is the expected behaviour when creating a new repository, it\nis not when reinitializing a repository: we should retain the ref format\ncurrently used by it in that case.\n\nThis doesn't work correctly right now:\n\n    $ git init --ref-format=files repo\n    Initialized empty Git repository in /tmp/repo/.git/\n    $ GIT_DEFAULT_REF_FORMAT=reftable git init repo\n    fatal: could not open '/tmp/repo/.git/refs/heads' for writing: Is a directory\n\nInstead of retaining the current ref format, the reinitialization tries\nto reinitialize the repository with the different format. This action\nfails when git-init(1) tries to write the \".git/refs/heads\" stub, which\nin the context of the reftable backend is always written as a file so\nthat we can detect clients which inadvertently try to access the repo\nwith the wrong ref format. Seems like the protection mechanism works for\nthis case, as well.\n\nFix the issue by ignoring the environment variable in case the repo has\nalready been initialized with a ref storage format.\n\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n setup.c         | 4 +++-\n t/t0001-init.sh | 9 +++++++++\n 2 files changed, 12 insertions(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex 8a488f3e7c..53ffeabc5b 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -2534,7 +2534,9 @@ static void repository_format_configure(struct repository_format *repo_fmt,\n \t\tref_format = ref_storage_format_by_name(env);\n \t\tif (ref_format == REF_STORAGE_FORMAT_UNKNOWN)\n \t\t\tdie(_(\"unknown ref storage format '%s'\"), env);\n-\t\trepo_fmt->ref_storage_format = ref_format;\n+\t\tif (repo_fmt->version < 0 ||\n+\t\t    repo_fmt->ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)\n+\t\t\trepo_fmt->ref_storage_format = ref_format;\n \t} else if (cfg.ref_format != REF_STORAGE_FORMAT_UNKNOWN) {\n \t\trepo_fmt->ref_storage_format = cfg.ref_format;\n \t}\ndiff --git a/t/t0001-init.sh b/t/t0001-init.sh\nindex 213d5984b1..6dff8b75f1 100755\n--- a/t/t0001-init.sh\n+++ b/t/t0001-init.sh\n@@ -697,6 +697,15 @@ do\n \t\tgit -C refformat rev-parse --show-ref-format >actual &&\n \t\ttest_cmp expect actual\n \t'\n+\n+\ttest_expect_success \"reinit repository with GIT_DEFAULT_REF_FORMAT=$format does not change format\" '\n+\t\ttest_when_finished \"rm -rf refformat\" &&\n+\t\tgit init refformat &&\n+\t\tgit -C refformat rev-parse --show-ref-format >expect &&\n+\t\tGIT_DEFAULT_REF_FORMAT=$format git init refformat &&\n+\t\tgit -C refformat rev-parse --show-ref-format >actual &&\n+\t\ttest_cmp expect actual\n+\t'\n done\n \n test_expect_success \"--ref-format= overrides GIT_DEFAULT_REF_FORMAT\" '\n\n-- \n2.48.1.468.gbf5f394be8.dirty\n\n"},{"id":"511531","messageId":"xmqqy0ys9b97.fsf@gitster.g","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-2-d2769ca01207@pks.im","subject":"Re: [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-30T22:40:04Z","receivedAt":"2025-01-30T22:40:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> The GIT_DEFAULT_REF_FORMAT environment variable can be set to influence\n> the default ref format that new repostiories shall be initialized with.\n> While this is the expected behaviour when creating a new repository, it\n> is not when reinitializing a repository: we should retain the ref format\n> currently used by it in that case.\n>\n> This doesn't work correctly right now:\n>\n>     $ git init --ref-format=files repo\n>     Initialized empty Git repository in /tmp/repo/.git/\n>     $ GIT_DEFAULT_REF_FORMAT=reftable git init repo\n>     fatal: could not open '/tmp/repo/.git/refs/heads' for writing: Is a directory\n>\n> Instead of retaining the current ref format, the reinitialization tries\n> to reinitialize the repository with the different format. This action\n> fails when git-init(1) tries to write the \".git/refs/heads\" stub, which\n> in the context of the reftable backend is always written as a file so\n> that we can detect clients which inadvertently try to access the repo\n> with the wrong ref format. Seems like the protection mechanism works for\n> this case, as well.\n\nGood finding.  A plausible alternative behaviour could be to do the\nbackend migration when this is asked, and we might gain consensus to\ndo so in the (far) future, but I agree that it is a good direction\nto go in the short term to match the behaviour of the code to the\ndocumented expectation.\n\n"},{"id":"511532","messageId":"Z5wSEBZJU0qebKYY@tapette.crustytoothpaste.net","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-0-d2769ca01207@pks.im","subject":"Re: [PATCH 0/3] setup: fix reinit of repos with different formats","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-01-30T23:58:08Z","receivedAt":"2025-01-30T23:58:11Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-01-30 at 16:24:16, Patrick Steinhardt wrote:\n> Hi,\n> \n> this issue with the reinitialization of the ref format was recently\n> discovered in our CI systems at GitLab, where caches contained repos\n> with one ref format but we tried to reinit them with a different ref\n> format. But turns out that the same issue also exists for the object\n> format, so this patch series fixes both issues.\n\nI looked at this series and it seems reasonable.  As you mentioned,\nreinitializing the repository in this way cannot possibly work in any\nmeaningful sense, so rejecting it is the prudent thing to do.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"511602","messageId":"xmqqv7tu623n.fsf@gitster.g","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-2-d2769ca01207@pks.im","subject":"Re: [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-31T22:38:20Z","receivedAt":"2025-01-31T22:38:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> Instead of retaining the current ref format, the reinitialization tries\n> to reinitialize the repository with the different format. This action\n> fails when git-init(1) tries to write the \".git/refs/heads\" stub, which\n> in the context of the reftable backend is always written as a file so\n> that we can detect clients which inadvertently try to access the repo\n> with the wrong ref format. Seems like the protection mechanism works for\n> this case, as well.\n>\n> Fix the issue by ignoring the environment variable in case the repo has\n> already been initialized with a ref storage format.\n\nIt certainly is better than corrupting the repository, but if we are\nto do this change, shouldn't we at least issue a warning to tell\nusers that (a part of) their request was ignored, instead of\nsilently ignoring the specified ref-format?\n\n> Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> ---\n>  setup.c         | 4 +++-\n>  t/t0001-init.sh | 9 +++++++++\n>  2 files changed, 12 insertions(+), 1 deletion(-)\n>\n> diff --git a/setup.c b/setup.c\n> index 8a488f3e7c..53ffeabc5b 100644\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -2534,7 +2534,9 @@ static void repository_format_configure(struct repository_format *repo_fmt,\n>  \t\tref_format = ref_storage_format_by_name(env);\n>  \t\tif (ref_format == REF_STORAGE_FORMAT_UNKNOWN)\n>  \t\t\tdie(_(\"unknown ref storage format '%s'\"), env);\n> -\t\trepo_fmt->ref_storage_format = ref_format;\n> +\t\tif (repo_fmt->version < 0 ||\n> +\t\t    repo_fmt->ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)\n> +\t\t\trepo_fmt->ref_storage_format = ref_format;\n\nPerhaps something silly like this?\n\n\t\tif (0 <= repo_fmt->version &&\n\t\t    repo_fmt->ref_storage_format != REF_STORAGE_FORMAT_UNKNOWN)\n\t\t\twarning(\"ignoring the specified ref-format\");\n\t\telse\n\t\t\trepo_fmt->ref_storage_format = ref_format;\n\nIn the longer term, we might want to consider automatically\nmigrating the ref backend (by calling into \"git ref migrate\"),\nbut it is a good first move to stop damaging the repository.\n\nThanks.\n"},{"id":"511603","messageId":"xmqqr04i61zo.fsf@gitster.g","threadId":"62875","inReplyTo":"20250130-b4-pks-reinit-default-ref-format-v1-3-d2769ca01207@pks.im","subject":"Re: [PATCH 3/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_HASH","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-31T22:40:43Z","receivedAt":"2025-01-31T22:40:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> The exact same issue as described in the preceding commit also exists\n> for GIT_DEFAULT_HASH. Thus, reinitializing a repository that e.g. uses\n> SHA1 with `GIT_DEFAULT_HASH=sha256 git init` will cause the object\n> format of that repository to change to SHA256. This is of course bogus\n> as any existing objects and refs will not be converted, thus causing\n> repository corruption:\n\nThe exact same comment on silently ignoring applies, but unlike the\nprevious one, converting the entire history is far more expensive,\nso it may be much less likely to be worth going the automatic\nconversion route than the previous one.\n\nThanks.\n\n"},{"id":"511673","messageId":"Z6BUOs7k1rzGOGTN@pks.im","threadId":"62875","inReplyTo":"xmqqv7tu623n.fsf@gitster.g","subject":"Re: [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-02-03T05:29:30Z","receivedAt":"2025-02-03T05:29:35Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Jan 31, 2025 at 02:38:20PM -0800, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > Instead of retaining the current ref format, the reinitialization tries\n> > to reinitialize the repository with the different format. This action\n> > fails when git-init(1) tries to write the \".git/refs/heads\" stub, which\n> > in the context of the reftable backend is always written as a file so\n> > that we can detect clients which inadvertently try to access the repo\n> > with the wrong ref format. Seems like the protection mechanism works for\n> > this case, as well.\n> >\n> > Fix the issue by ignoring the environment variable in case the repo has\n> > already been initialized with a ref storage format.\n> \n> It certainly is better than corrupting the repository, but if we are\n> to do this change, shouldn't we at least issue a warning to tell\n> users that (a part of) their request was ignored, instead of\n> silently ignoring the specified ref-format?\n\nI don't think we should. If this was passed on the command line then\nyes, we should flag this and already die indeed. But this is an\nenvironment variable that allows you to set the default format. From my\npoint of view it is totally expected that this doesn't cause the format\nof existing repositories to change.\n\n> > Signed-off-by: Patrick Steinhardt <ps@pks.im>\n> > ---\n> >  setup.c         | 4 +++-\n> >  t/t0001-init.sh | 9 +++++++++\n> >  2 files changed, 12 insertions(+), 1 deletion(-)\n> >\n> > diff --git a/setup.c b/setup.c\n> > index 8a488f3e7c..53ffeabc5b 100644\n> > --- a/setup.c\n> > +++ b/setup.c\n> > @@ -2534,7 +2534,9 @@ static void repository_format_configure(struct repository_format *repo_fmt,\n> >  \t\tref_format = ref_storage_format_by_name(env);\n> >  \t\tif (ref_format == REF_STORAGE_FORMAT_UNKNOWN)\n> >  \t\t\tdie(_(\"unknown ref storage format '%s'\"), env);\n> > -\t\trepo_fmt->ref_storage_format = ref_format;\n> > +\t\tif (repo_fmt->version < 0 ||\n> > +\t\t    repo_fmt->ref_storage_format == REF_STORAGE_FORMAT_UNKNOWN)\n> > +\t\t\trepo_fmt->ref_storage_format = ref_format;\n> \n> Perhaps something silly like this?\n> \n> \t\tif (0 <= repo_fmt->version &&\n> \t\t    repo_fmt->ref_storage_format != REF_STORAGE_FORMAT_UNKNOWN)\n> \t\t\twarning(\"ignoring the specified ref-format\");\n> \t\telse\n> \t\t\trepo_fmt->ref_storage_format = ref_format;\n> \n> In the longer term, we might want to consider automatically\n> migrating the ref backend (by calling into \"git ref migrate\"),\n> but it is a good first move to stop damaging the repository.\n\nI think keeping migrations explicit is worthwhile. Migrations are a\nsomewhat risky thing, so explicitly making the user ask for them is not\na bad thing. I personally wouldn't expect git-init(1) to migrate data.\nAfter all, it is supposed to initialize stuff, not rewrite it.\n\nThis is doubly true for environment variables, where it is so extremely\neasy to accidentally still have them defined. I don't think implicitly\nconverting every git-init(1) to do migrations would be a good idea there\nas it would likely do the wrong thing in many cases.\n\nSo from my point of view we should treat the environment variables the\nsame as we treat \"init.defaultRefFormat\" and \"init.defaultObjectFormat\".\nThose indicate defaults, but do not cause us to change the format of\nexisting repostiories.\n\nPatrick\n"},{"id":"511734","messageId":"xmqqikpryvnm.fsf@gitster.g","threadId":"62875","inReplyTo":"Z6BUOs7k1rzGOGTN@pks.im","subject":"Re: [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-03T14:01:33Z","receivedAt":"2025-02-03T14:01:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> So from my point of view we should treat the environment variables the\n> same as we treat \"init.defaultRefFormat\" and \"init.defaultObjectFormat\".\n> Those indicate defaults, but do not cause us to change the format of\n> existing repostiories.\n\nHmph, as somebody who often does things like\n\n    $ GIT_EDITOR=: git do-something\n    $ GIT_AUTHOR_NAME=foo GIT_AUTHOR_EMAIL=bar@baz git commit -a\n\nI do not necessarily see the environment variables as replacement\nfor configured defaults.  They are, at least to me, more like a\nsingle-shot override of the configured defaults, so if we were to\ncomplain and error out command line options (we do do so, don't we?),\nI would expect the environment variable that gives a single-shot\nsetting to be treated the same way.\n\nThanks.\n\n\n\n"},{"id":"511739","messageId":"Z6DabWZqB5QJed3F@pks.im","threadId":"62875","inReplyTo":"xmqqikpryvnm.fsf@gitster.g","subject":"Re: [PATCH 2/3] setup: fix reinit of repos with incompatible GIT_DEFAULT_REF_FORMAT","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-02-03T15:02:05Z","receivedAt":"2025-02-03T15:02:10Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Feb 03, 2025 at 06:01:33AM -0800, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > So from my point of view we should treat the environment variables the\n> > same as we treat \"init.defaultRefFormat\" and \"init.defaultObjectFormat\".\n> > Those indicate defaults, but do not cause us to change the format of\n> > existing repostiories.\n> \n> Hmph, as somebody who often does things like\n> \n>     $ GIT_EDITOR=: git do-something\n>     $ GIT_AUTHOR_NAME=foo GIT_AUTHOR_EMAIL=bar@baz git commit -a\n> \n> I do not necessarily see the environment variables as replacement\n> for configured defaults.  They are, at least to me, more like a\n> single-shot override of the configured defaults, so if we were to\n> complain and error out command line options (we do do so, don't we?),\n> I would expect the environment variable that gives a single-shot\n> setting to be treated the same way.\n\nEspecially the second one is a good example though that works mostly as\nI propose: GIT_AUTHOR_NAME will impact _new_ commits, but not _existing_\nones when you for example `--amend` the commit. So this is somewhat\nequivalent to how both GIT_DEFAULT_REF_FORMAT and GIT_DEFAULT_HASH work\nwith git-init(1), isn't it?\n\nPatrick\n"}]}