threads / patch / 53852

patchsetup: warn about un-enabled extensions

Subject: [PATCH] setup: warn about un-enabled extensions

## tl;dr

39 messages between Jul 13, 2020 and Jul 17, 2020. Diffs are folded; open one to read it.

replies: 38people: 5as markdown or json

Johannes Schindelin via GitGitGadget· Jul 13, 2020, 21:55 UTC · lore
From: Johannes Schindelin <johannes.schindelin@gmx.de>

When any `extensions.*` setting is configured, we newly ignore it unless `core.repositoryFormatVersion` is set to a positive value.

This might be quite surprising, e.g. when calling `git config --worktree [...]` elicits a warning that it requires `extensions.worktreeConfig = true` when that setting _is_ configured (but ignored because `core.repositoryFormatVersion` is unset).

Let's warn about this situation specifically, especially because there might be already setups out there that configured a sparse worktree using Git v2.27.0 (which does set `extensions.worktreeConfig` but not `core.repositoryFormatVersion`) and users might want to work in those setups with Git v2.28.0, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
    Warn when extensions.* is ignored
    
    I did actually run into this today. One of my pipelines is configured to
    clone a bare repository, then set up a sparse secondary worktree. This
    used to work, but all of a sudden, the git config --worktree
    core.sparseCheckout true call failed because I'm now using v2.28.0-rc0.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-675%2Fdscho%2Frepo-format-version-advice-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-675/dscho/repo-format-version-advice-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/675
 cache.h                    |  2 +-
 setup.c                    | 16 +++++++++++++++-
 t/t2404-worktree-config.sh | 15 +++++++++++++++
 3 files changed, 31 insertions(+), 2 deletions(-)
Show changes to 3 files +31 −2

cache.h, setup.c, t/t2404-worktree-config.sh

diff --git a/cache.h b/cache.h
index 126ec56c7f..da2c71f366 100644
--- a/cache.h
+++ b/cache.h
@@ -1042,7 +1042,7 @@ struct repository_format {
 	int worktree_config;
 	int is_bare;
 	int hash_algo;
-	int has_extensions;
+	int has_extensions, saw_extensions;
 	char *work_tree;
 	struct string_list unknown_extensions;
 };
diff --git a/setup.c b/setup.c
index dbac2eabe8..0f45e2e174 100644
--- a/setup.c
+++ b/setup.c
@@ -489,6 +489,15 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
 	read_repository_format(candidate, sb.buf);
 	strbuf_release(&sb);
 
+	if (candidate->version < 1 &&
+	    (candidate->saw_extensions || candidate->has_extensions))
+		advise(_("extensions.* settings require a positive repository "
+			 "format version greater than zero.\n"
+			 "\n"
+			 "Please use the following call to enable extensions.* "
+			 "config settings:\n"
+			 "\"git config core.repositoryFormatVersion 1\""));
+
 	/*
 	 * For historical use of check_repository_format() in git-init,
 	 * we treat a missing config as a silent "ok", even when nongit_ok
@@ -584,8 +593,13 @@ int read_repository_format(struct repository_format *format, const char *path)
 {
 	clear_repository_format(format);
 	git_config_from_file(check_repo_format, path, format);
-	if (format->version == -1)
+	if (format->version == -1) {
+		int saw_extensions = format->has_extensions;
+
 		clear_repository_format(format);
+
+		format->saw_extensions = saw_extensions;
+	}
 	return format->version;
 }
 
diff --git a/t/t2404-worktree-config.sh b/t/t2404-worktree-config.sh
index 9536d10919..1c08a45177 100755
--- a/t/t2404-worktree-config.sh
+++ b/t/t2404-worktree-config.sh
@@ -78,4 +78,19 @@ test_expect_success 'config.worktree no longer read without extension' '
 	test_cmp_config -C wt2 shared this.is
 '
 
+test_expect_success 'show advice when extensions.* are not enabled' '
+	test_config core.repositoryformatversion 1 &&
+	test_config extensions.worktreeConfig true &&
+	git status 2>err &&
+	test_i18ngrep ! "git config core.repositoryFormatVersion 1" err &&
+
+	test_config core.repositoryformatversion 0 &&
+	git status 2>err &&
+	test_i18ngrep "git config core.repositoryFormatVersion 1" err &&
+
+	git config --unset core.repositoryformatversion &&
+	git status 2>err &&
+	test_i18ngrep "git config core.repositoryFormatVersion 1" err
+'
+
 test_done

base-commit: bd42bbe1a46c0fe486fc33e82969275e27e4dc19
-- 
gitgitgadget
Junio C Hamano· Jul 13, 2020, 22:48 UTC · re: Johannes Schindelin via GitGitGadget · lore

Re: [PATCH] setup: warn about un-enabled extensions

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

>     I did actually run into this today. One of my pipelines is configured to
>     clone a bare repository, then set up a sparse secondary worktree. This
>     used to work, but all of a sudden, the git config --worktree
>     core.sparseCheckout true call failed because I'm now using v2.28.0-rc0.

I guess a few people were independently hit and then approached the same issue from different angles? If so, can you two compare notes to help us all come up with a single good solution, preferrably by -rc1?

Thanks.
Derrick Stolee· Jul 14, 2020, 00:24 UTC · re: Johannes Schindelin via GitGitGadget · lore

Re: [PATCH] setup: warn about un-enabled extensions

On 7/13/2020 5:55 PM, Johannes Schindelin via GitGitGadget wrote:
Show 24 quoted lines
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> When any `extensions.*` setting is configured, we newly ignore it unless
> `core.repositoryFormatVersion` is set to a positive value.
> 
> This might be quite surprising, e.g. when calling `git config --worktree
> [...]` elicits a warning that it requires
> `extensions.worktreeConfig = true` when that setting _is_ configured
> (but ignored because `core.repositoryFormatVersion` is unset).
> 
> Let's warn about this situation specifically, especially because there
> might be already setups out there that configured a sparse worktree
> using Git v2.27.0 (which does set `extensions.worktreeConfig` but not
> `core.repositoryFormatVersion`) and users might want to work in those
> setups with Git v2.28.0, too.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>     Warn when extensions.* is ignored
>     
>     I did actually run into this today. One of my pipelines is configured to
>     clone a bare repository, then set up a sparse secondary worktree. This
>     used to work, but all of a sudden, the git config --worktree
>     core.sparseCheckout true call failed because I'm now using v2.28.0-rc0.
I tried your situation with Junio's patch from earlier [1] [2].

[1] https://lore.kernel.org/git/pull.674.git.1594668051847.gitgitgadget@gmail.com/ [2] https://lore.kernel.org/git/xmqqpn8zmao1.fsf_-_@gitster.c.googlers.com/

The issue here is that Junio's silent fix for sparse-checkout doesn't work here for "git config --worktree". However, I think that Johannes is making the same over-compensating warning message pattern as I was. That is, this warning happens for all extensions that are enabled when core.repositoryFormatVersion is less than 1.

To attempt to summarize Junio's opinion, we should keep our situation isolated to this worktree config extension. Your patch does agree with the others in that we don't revert the behavior of failing to set the config, but I think in this instance we can specify the warning more carefully.

If you don't mind, I was already going to squash Junio's commit into mine (almost completely replacing mine) but I could add a small commit on top that provides the following improvement to the error message:

Show changes to builtin/config.c +3 −3
diff --git a/builtin/config.c b/builtin/config.c
index 5e39f618854..b5de7982a93 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -678,8 +678,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)
                else if (worktrees[0] && worktrees[1])
                        die(_("--worktree cannot be used with multiple "
                              "working trees unless the config\n"
-                             "extension worktreeConfig is enabled. "
-                             "Please read \"CONFIGURATION FILE\"\n"
+                             "extension worktreeConfig is enabled "
+                             "and core.repositoryFormatVersion is at least\n"
+                             "1. Please read \"CONFIGURATION FILE\""
                              "section in \"git help worktree\" for details"));
                else
                        given_config_source.file = git_pathdup("config");

Thanks,
-Stolee
Johannes Schindelin· Jul 14, 2020, 12:21 UTC · re: Derrick Stolee · lore

Re: [PATCH] setup: warn about un-enabled extensions

Hi Stolee,
On Mon, 13 Jul 2020, Derrick Stolee wrote:
Show 42 quoted lines
> On 7/13/2020 5:55 PM, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > When any `extensions.*` setting is configured, we newly ignore it unless
> > `core.repositoryFormatVersion` is set to a positive value.
> >
> > This might be quite surprising, e.g. when calling `git config --worktree
> > [...]` elicits a warning that it requires
> > `extensions.worktreeConfig = true` when that setting _is_ configured
> > (but ignored because `core.repositoryFormatVersion` is unset).
> >
> > Let's warn about this situation specifically, especially because there
> > might be already setups out there that configured a sparse worktree
> > using Git v2.27.0 (which does set `extensions.worktreeConfig` but not
> > `core.repositoryFormatVersion`) and users might want to work in those
> > setups with Git v2.28.0, too.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >     Warn when extensions.* is ignored
> >
> >     I did actually run into this today. One of my pipelines is configured to
> >     clone a bare repository, then set up a sparse secondary worktree. This
> >     used to work, but all of a sudden, the git config --worktree
> >     core.sparseCheckout true call failed because I'm now using v2.28.0-rc0.
>
> I tried your situation with Junio's patch from earlier [1] [2].
>
> [1] https://lore.kernel.org/git/pull.674.git.1594668051847.gitgitgadget@gmail.com/
> [2] https://lore.kernel.org/git/xmqqpn8zmao1.fsf_-_@gitster.c.googlers.com/
>
> The issue here is that Junio's silent fix for sparse-checkout doesn't
> work here for "git config --worktree". However, I think that Johannes
> is making the same over-compensating warning message pattern as I was.
> That is, this warning happens for all extensions that are enabled when
> core.repositoryFormatVersion is less than 1.
>
> To attempt to summarize Junio's opinion, we should keep our situation
> isolated to this worktree config extension. Your patch does agree with
> the others in that we don't revert the behavior of failing to set the
> config, but I think in this instance we can specify the warning more
> carefully.
Okay.
> If you don't mind, I was already going to squash Junio's commit into
> mine (almost completely replacing mine) but I could add a small
> commit on top that provides the following improvement to the error
> message:

I don't mind at all. I'd just like to know that v2.28.0 avoids confusing users in the same was as v2.28.0-rc0 confused me.

Thanks, Dscho

Show 22 quoted lines
>
> diff --git a/builtin/config.c b/builtin/config.c
> index 5e39f618854..b5de7982a93 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -678,8 +678,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)
>                 else if (worktrees[0] && worktrees[1])
>                         die(_("--worktree cannot be used with multiple "
>                               "working trees unless the config\n"
> -                             "extension worktreeConfig is enabled. "
> -                             "Please read \"CONFIGURATION FILE\"\n"
> +                             "extension worktreeConfig is enabled "
> +                             "and core.repositoryFormatVersion is at least\n"
> +                             "1. Please read \"CONFIGURATION FILE\""
>                               "section in \"git help worktree\" for details"));
>                 else
>                         given_config_source.file = git_pathdup("config");
>
> Thanks,
> -Stolee
>
>
Junio C Hamano· Jul 14, 2020, 15:27 UTC · re: Johannes Schindelin · lore

Re: [PATCH] setup: warn about un-enabled extensions

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 7 quoted lines
>> If you don't mind, I was already going to squash Junio's commit into
>> mine (almost completely replacing mine) but I could add a small
>> commit on top that provides the following improvement to the error
>> message:
>
> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing
> users in the same was as v2.28.0-rc0 confused me.

In a nearby thread, Jonathan Nieder raised an interesting approach to avoid confusing users, which I think (if I am reading him correctly) makes sense (cf. <20200714040616.GA2208896@google.com>)

What if we accept the extensions the code before the topic in question that was merged in -rc0 introduced the "confusion" accepts even in v0? If we see extensions other than those handpicked and grandfathered ones (which are presumably the ones we add later and support in v1 and later repository versions) in a v0 repository, we keep ignoring. Also we'd loosen the overly strict code that prevents upgrading from v0 to v1 in the presence of any extensions in -rc0, so that the grandfathered ones will not prevent the upgrading.

The original reasoning behind the strict check was because the users could have used extensions.frotz for their own use with their own meaning, trusting that Git would simply ignore it, and an upgrade to later version in which Git uses extensions.frotz for a purpose that is unrelated to the reason why these users used would just break the repository.

But the ones that were (accidentally) honored in v0 couldn't have been used by the users for the purposes other than how Git would use them anyway, so there is no point to make them prevent the upgrade of the repository version from v0 to v1.

At least, that is how I understood the world would look like in Jonathan's "different endgame".

What do you three (Dscho, Derrick and Jonathan) think?  
Show 25 quoted lines
> Thanks,
> Dscho
>
>>
>> diff --git a/builtin/config.c b/builtin/config.c
>> index 5e39f618854..b5de7982a93 100644
>> --- a/builtin/config.c
>> +++ b/builtin/config.c
>> @@ -678,8 +678,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)
>>                 else if (worktrees[0] && worktrees[1])
>>                         die(_("--worktree cannot be used with multiple "
>>                               "working trees unless the config\n"
>> -                             "extension worktreeConfig is enabled. "
>> -                             "Please read \"CONFIGURATION FILE\"\n"
>> +                             "extension worktreeConfig is enabled "
>> +                             "and core.repositoryFormatVersion is at least\n"
>> +                             "1. Please read \"CONFIGURATION FILE\""
>>                               "section in \"git help worktree\" for details"));
>>                 else
>>                         given_config_source.file = git_pathdup("config");
>>
>> Thanks,
>> -Stolee
>>
>>
Derrick Stolee· Jul 14, 2020, 15:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

On 7/14/2020 11:27 AM, Junio C Hamano wrote:
Show 40 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>>> If you don't mind, I was already going to squash Junio's commit into
>>> mine (almost completely replacing mine) but I could add a small
>>> commit on top that provides the following improvement to the error
>>> message:
>>
>> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing
>> users in the same was as v2.28.0-rc0 confused me.
> 
> In a nearby thread, Jonathan Nieder raised an interesting approach
> to avoid confusing users, which I think (if I am reading him
> correctly) makes sense (cf. <20200714040616.GA2208896@google.com>)
> 
> What if we accept the extensions the code before the topic in
> question that was merged in -rc0 introduced the "confusion" accepts
> even in v0?  If we see extensions other than those handpicked and
> grandfathered ones (which are presumably the ones we add later and
> support in v1 and later repository versions) in a v0 repository, we
> keep ignoring.  Also we'd loosen the overly strict code that
> prevents upgrading from v0 to v1 in the presence of any extensions
> in -rc0, so that the grandfathered ones will not prevent the
> upgrading.
> 
> The original reasoning behind the strict check was because the users
> could have used extensions.frotz for their own use with their own
> meaning, trusting that Git would simply ignore it, and an upgrade to
> later version in which Git uses extensions.frotz for a purpose that
> is unrelated to the reason why these users used would just break the
> repository.  
> 
> But the ones that were (accidentally) honored in v0 couldn't have
> been used by the users for the purposes other than how Git would use
> them anyway, so there is no point to make them prevent the upgrade
> of the repository version from v0 to v1.
> 
> At least, that is how I understood the world would look like in
> Jonathan's "different endgame".
> 
> What do you three (Dscho, Derrick and Jonathan) think?  

If "v0" includes "core.repositoryFormatVersion is unset" then I would consider this to be a way to avoid all user pain, which is positive.

I'd be happy to test and review a patch that accomplishes this goal.

CC'ing Ed Thomson because this extension stuff affects other tools, like libgit2.

Thanks, -Stolee

Johannes Schindelin· Jul 14, 2020, 20:30 UTC · re: Derrick Stolee · lore

Re: [PATCH] setup: warn about un-enabled extensions

Hi,
On Tue, 14 Jul 2020, Derrick Stolee wrote:
Show 45 quoted lines
> On 7/14/2020 11:27 AM, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >>> If you don't mind, I was already going to squash Junio's commit into
> >>> mine (almost completely replacing mine) but I could add a small
> >>> commit on top that provides the following improvement to the error
> >>> message:
> >>
> >> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing
> >> users in the same was as v2.28.0-rc0 confused me.
> >
> > In a nearby thread, Jonathan Nieder raised an interesting approach
> > to avoid confusing users, which I think (if I am reading him
> > correctly) makes sense (cf. <20200714040616.GA2208896@google.com>)
> >
> > What if we accept the extensions the code before the topic in
> > question that was merged in -rc0 introduced the "confusion" accepts
> > even in v0?  If we see extensions other than those handpicked and
> > grandfathered ones (which are presumably the ones we add later and
> > support in v1 and later repository versions) in a v0 repository, we
> > keep ignoring.  Also we'd loosen the overly strict code that
> > prevents upgrading from v0 to v1 in the presence of any extensions
> > in -rc0, so that the grandfathered ones will not prevent the
> > upgrading.
> >
> > The original reasoning behind the strict check was because the users
> > could have used extensions.frotz for their own use with their own
> > meaning, trusting that Git would simply ignore it, and an upgrade to
> > later version in which Git uses extensions.frotz for a purpose that
> > is unrelated to the reason why these users used would just break the
> > repository.
> >
> > But the ones that were (accidentally) honored in v0 couldn't have
> > been used by the users for the purposes other than how Git would use
> > them anyway, so there is no point to make them prevent the upgrade
> > of the repository version from v0 to v1.
> >
> > At least, that is how I understood the world would look like in
> > Jonathan's "different endgame".
> >
> > What do you three (Dscho, Derrick and Jonathan) think?
>
> If "v0" includes "core.repositoryFormatVersion is unset" then I
> would consider this to be a way to avoid all user pain, which is
> positive.
I concur.
> I'd be happy to test and review a patch that accomplishes this
> goal.

Wouldn't that just be a matter of extending your patch to re-set `has_unhandled_extensions` also for `preciousObjects` and `partialClone`?

Ciao, Dscho

Show 8 quoted lines
>
> CC'ing Ed Thomson because this extension stuff affects other tools,
> like libgit2.
>
> Thanks,
> -Stolee
>
>
Junio C Hamano· Jul 14, 2020, 20:47 UTC · re: Johannes Schindelin · lore

Re: [PATCH] setup: warn about un-enabled extensions

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 13 quoted lines
> On Tue, 14 Jul 2020, Derrick Stolee wrote:
>
>> If "v0" includes "core.repositoryFormatVersion is unset" then I
>> would consider this to be a way to avoid all user pain, which is
>> positive.
>
> I concur.
>
>> I'd be happy to test and review a patch that accomplishes this
>> goal.
>
> Wouldn't that just be a matter of extending your patch to re-set
> `has_unhandled_extensions` also for `preciousObjects` and `partialClone`?

It probably needs a bit more than that. For example there is this bit in check_repository_format_gently() that clears the unwanted extensions that we used to honor by mistake in v0 repository

	if (candidate->version >= 1) {
		repository_format_precious_objects = candidate->precious_objects;
		set_repository_format_partial_clone(candidate->partial_clone);
		repository_format_worktree_config = candidate->worktree_config;
	} else {
		repository_format_precious_objects = 0;
		set_repository_format_partial_clone(NULL);
		repository_format_worktree_config = 0;
	}

and the "different endgame" advocates to keep honoring these (and only these), the else clause probably needs to go. There may be some other tweaks necessary.

Junio C Hamano· Jul 15, 2020, 16:09 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

Junio C Hamano <gitster@pobox.com> writes:
Show 40 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> If you don't mind, I was already going to squash Junio's commit into
>>> mine (almost completely replacing mine) but I could add a small
>>> commit on top that provides the following improvement to the error
>>> message:
>>
>> I don't mind at all. I'd just like to know that v2.28.0 avoids confusing
>> users in the same was as v2.28.0-rc0 confused me.
>
> In a nearby thread, Jonathan Nieder raised an interesting approach
> to avoid confusing users, which I think (if I am reading him
> correctly) makes sense (cf. <20200714040616.GA2208896@google.com>)
>
> What if we accept the extensions the code before the topic in
> question that was merged in -rc0 introduced the "confusion" accepts
> even in v0?  If we see extensions other than those handpicked and
> grandfathered ones (which are presumably the ones we add later and
> support in v1 and later repository versions) in a v0 repository, we
> keep ignoring.  Also we'd loosen the overly strict code that
> prevents upgrading from v0 to v1 in the presence of any extensions
> in -rc0, so that the grandfathered ones will not prevent the
> upgrading.
>
> The original reasoning behind the strict check was because the users
> could have used extensions.frotz for their own use with their own
> meaning, trusting that Git would simply ignore it, and an upgrade to
> later version in which Git uses extensions.frotz for a purpose that
> is unrelated to the reason why these users used would just break the
> repository.  
>
> But the ones that were (accidentally) honored in v0 couldn't have
> been used by the users for the purposes other than how Git would use
> them anyway, so there is no point to make them prevent the upgrade
> of the repository version from v0 to v1.
>
> At least, that is how I understood the world would look like in
> Jonathan's "different endgame".
>
> What do you three (Dscho, Derrick and Jonathan) think?  

It seems that there is no quick concensus to go with your "different endgame" and worse yet it seems nobody is interested in helping much.

The current one on the table is NOT <20200714040616.GA2208896@google.com> but the two patches

<1b26d9710a7ffaca0bad1f4e1c1729f501ed1559.1594690017.git.gitgitgadget@gmail.com> <e11e973c6fff6a523da090f7294234902e65a9d0.1594690017.git.gitgitgadget@gmail.com>

which we may regret---it is far from a robust and complete solution, but probably specific to users at Microsoft or something like that. For example it special cases only the worktreeconfig and nothing else, even though I suspect that other configuration variables were also honored by mistake.

So...

Here is my quick attempt to see how far we can go with the "different endgame" approach, to be applied on top of those two patches. It still has two known "breakages" and can use help from extra eyeballs and real work.

I suspect that an expected test_must_fail not triggering t2404 may even be a good thing if it is a sign of silent upgrading of the repository version due to having grandfathered extensions in a v0 repository, but I didn't have time to dig further.

I'll shift my attention to other topics that should be in the release for the rest of the day, but am pessimistic that I can tag the -rc1 today, which won't happen until we at least have a concensus on what to do with the (apparent) regression due to the "upgrade repository version" topic.

Thanks.
 setup.c                    | 52 +++++++++++++++++++++++++++-------------------
 t/t0410-partial-clone.sh   | 14 ++++++++++++-
 t/t2404-worktree-config.sh |  2 +-
 3 files changed, 45 insertions(+), 23 deletions(-)
Show changes to 3 files +45 −23

setup.c, t/t0410-partial-clone.sh, t/t2404-worktree-config.sh

diff --git a/setup.c b/setup.c
index 65270440a9..fe4e1ec066 100644
--- a/setup.c
+++ b/setup.c
@@ -455,28 +455,37 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
 	if (strcmp(var, "core.repositoryformatversion") == 0)
 		data->version = git_config_int(var, value);
 	else if (skip_prefix(var, "extensions.", &ext)) {
+		int unallowed_in_v0 = 1;
+
 		/*
-		 * record any known extensions here; otherwise,
-		 * we fall through to recording it as unknown, and
-		 * check_repository_format will complain
+		 * The early ones are grandfathered---they existed in
+		 * 2.27 which mistakenly honored even in repositories
+		 * whose version is before v1 (where extensions are
+		 * officially introduced).
 		 */
-		int is_unallowed_extension = 1;
-
-		if (!strcmp(ext, "noop"))
-			;
-		else if (!strcmp(ext, "preciousobjects"))
+		if (!strcmp(ext, "noop")) {
+			unallowed_in_v0 = 0;
+		} else if (!strcmp(ext, "preciousobjects")) {
 			data->precious_objects = git_config_bool(var, value);
-		else if (!strcmp(ext, "partialclone")) {
+			unallowed_in_v0 = 0;
+		} else if (!strcmp(ext, "partialclone")) {
 			if (!value)
 				return config_error_nonbool(var);
 			data->partial_clone = xstrdup(value);
+			unallowed_in_v0 = 0;
 		} else if (!strcmp(ext, "worktreeconfig")) {
 			data->worktree_config = git_config_bool(var, value);
-			is_unallowed_extension = 0;
-		} else
+			unallowed_in_v0 = 0;
+		/*
+		 * Extensions are added by more "} else if (...) {"
+		 * lines here, but do NOT mark them as allowed in v0
+		 * by copy-pasting without thinking.
+		 */
+		} else {
 			string_list_append(&data->unknown_extensions, ext);
+		}
 
-		data->has_unallowed_extensions |= is_unallowed_extension;
+		data->has_unallowed_extensions |= unallowed_in_v0;
 	}
 
 	return read_worktree_config(var, value, vdata);
@@ -511,15 +520,16 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
 		die("%s", err.buf);
 	}
 
-	if (candidate->version >= 1) {
-		repository_format_precious_objects = candidate->precious_objects;
-		set_repository_format_partial_clone(candidate->partial_clone);
-		repository_format_worktree_config = candidate->worktree_config;
-	} else {
-		repository_format_precious_objects = 0;
-		set_repository_format_partial_clone(NULL);
-		repository_format_worktree_config = 0;
-	}
+	/*
+	 * Now we know the extensions in "candidate" repository are
+	 * OK, let's copy them to the final place.  Note that this is
+	 * done even in v0 repositories, as long as the extensions are
+	 * the grandfathered ones that used to be honored by mistake.
+	 */
+	repository_format_precious_objects = candidate->precious_objects;
+	set_repository_format_partial_clone(candidate->partial_clone);
+	repository_format_worktree_config = candidate->worktree_config;
+
 	string_list_clear(&candidate->unknown_extensions, 0);
 
 	if (repository_format_worktree_config) {
diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
index 463dc3a8be..2fc2d0bbfc 100755
--- a/t/t0410-partial-clone.sh
+++ b/t/t0410-partial-clone.sh
@@ -42,7 +42,7 @@ test_expect_success 'convert shallow clone to partial clone' '
 	test_cmp_config -C client 1 core.repositoryformatversion
 '
 
-test_expect_success 'convert shallow clone to partial clone must fail with any extension' '
+test_expect_success 'convert shallow clone to partial clone succeeds with grandfathered extension' '
 	rm -fr server client &&
 	test_create_repo server &&
 	test_commit -C server my_commit 1 &&
@@ -50,6 +50,18 @@ test_expect_success 'convert shallow clone to partial clone must fail with any e
 	git clone --depth=1 "file://$(pwd)/server" client &&
 	test_cmp_config -C client 0 core.repositoryformatversion &&
 	git -C client config extensions.partialclone origin &&
+	git -C client fetch --unshallow --filter="blob:none"
+'
+
+test_expect_failure 'convert shallow clone to partial clone must fail with unknown extension' '
+	rm -fr server client &&
+	test_create_repo server &&
+	test_commit -C server my_commit 1 &&
+	test_commit -C server my_commit2 1 &&
+	git clone --depth=1 "file://$(pwd)/server" client &&
+	test_cmp_config -C client 0 core.repositoryformatversion &&
+	git -C client config extensions.unknownExtension true &&
+	git -C client config extensions.partialclone origin &&
 	test_must_fail git -C client fetch --unshallow --filter="blob:none"
 '
 
diff --git a/t/t2404-worktree-config.sh b/t/t2404-worktree-config.sh
index 303a2644bd..b8c12df534 100755
--- a/t/t2404-worktree-config.sh
+++ b/t/t2404-worktree-config.sh
@@ -77,7 +77,7 @@ test_expect_success 'config.worktree no longer read without extension' '
 	test_cmp_config -C wt1 shared this.is &&
 	test_cmp_config -C wt2 shared this.is
 '
-test_expect_success 'show advice when extensions.* are not enabled' '
+test_expect_failure 'show advice when extensions.* are not enabled' '
 	test_config core.repositoryformatversion 1 &&
 	test_config extensions.worktreeConfig true &&
 	git config --worktree test.one true &&
Junio C Hamano· Jul 15, 2020, 17:01 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> The current one on the table is NOT
> <20200714040616.GA2208896@google.com> but the two patches
>
> <1b26d9710a7ffaca0bad1f4e1c1729f501ed1559.1594690017.git.gitgitgadget@gmail.com>
> <e11e973c6fff6a523da090f7294234902e65a9d0.1594690017.git.gitgitgadget@gmail.com>
>
> For example it special cases only the worktreeconfig and nothing
> else, even though I suspect that other configuration variables were
> also honored by mistake.

The attached may be a less ambitious and less risky update for the upcoming release. It is to be applied on top of the two-patch series from Derrick, and just marks the other "known and honored back then by mistake" extensions as OK to be there for upgrading.

Thoughts? If people are happy with that, then we could apply and cut an -rc1 with it. Or if we are OK with the "just special case worktreeconfig; other extensions may have the same issue but we haven't heard actual complaints so we will leave them untouched", then -rc1 can be done with just those two patches.

Now I do need to shift my attention to other topics in flight.
Thanks.
 setup.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)
Show changes to setup.c +16 −11
diff --git a/setup.c b/setup.c
index 65270440a9..a072c76d05 100644
--- a/setup.c
+++ b/setup.c
@@ -456,27 +456,32 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
 		data->version = git_config_int(var, value);
 	else if (skip_prefix(var, "extensions.", &ext)) {
 		/*
-		 * record any known extensions here; otherwise,
-		 * we fall through to recording it as unknown, and
-		 * check_repository_format will complain
+		 * Grandfather extensions that were known in 2.27 and
+		 * were honored by mistake even in v0 repositories; it
+		 * shoudn't be an error to upgrade v0 to v1 with them
+		 * in the repository, as they couldn't have been used
+		 * for incompatible purposes by the end user.
 		 */
-		int is_unallowed_extension = 1;
+		int unallowed_in_v0 = 1;
 
-		if (!strcmp(ext, "noop"))
-			;
-		else if (!strcmp(ext, "preciousobjects"))
+		if (!strcmp(ext, "noop")) {
+			unallowed_in_v0 = 0;
+		} else if (!strcmp(ext, "preciousobjects")) {
 			data->precious_objects = git_config_bool(var, value);
-		else if (!strcmp(ext, "partialclone")) {
+			unallowed_in_v0 = 0;
+		} else if (!strcmp(ext, "partialclone")) {
 			if (!value)
 				return config_error_nonbool(var);
 			data->partial_clone = xstrdup(value);
+			unallowed_in_v0 = 0;
 		} else if (!strcmp(ext, "worktreeconfig")) {
 			data->worktree_config = git_config_bool(var, value);
-			is_unallowed_extension = 0;
-		} else
+			unallowed_in_v0 = 0;
+		} else {
 			string_list_append(&data->unknown_extensions, ext);
+		}
 
-		data->has_unallowed_extensions |= is_unallowed_extension;
+		data->has_unallowed_extensions |= unallowed_in_v0;
 	}
 
 	return read_worktree_config(var, value, vdata);
Derrick Stolee· Jul 15, 2020, 18:00 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

On 7/15/2020 1:01 PM, Junio C Hamano wrote:
Show 11 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> The current one on the table is NOT
>> <20200714040616.GA2208896@google.com> but the two patches
>>
>> <1b26d9710a7ffaca0bad1f4e1c1729f501ed1559.1594690017.git.gitgitgadget@gmail.com>
>> <e11e973c6fff6a523da090f7294234902e65a9d0.1594690017.git.gitgitgadget@gmail.com>
>>
>> For example it special cases only the worktreeconfig and nothing
>> else, even though I suspect that other configuration variables were
>> also honored by mistake.

Sorry for the delay. I had your previous diff applied and was playing around with the two "known breakages".

The diff below _does_ fail on t0410-partial-clone.sh, but it's because you do change the behavior. Here is my diff hunk for that test:

Show changes to t/t0410-partial-clone.sh +20 −3
diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
index 463dc3a8be..fc8da56528 100755
--- a/t/t0410-partial-clone.sh
+++ b/t/t0410-partial-clone.sh
@@ -42,7 +42,7 @@ test_expect_success 'convert shallow clone to partial clone' '
        test_cmp_config -C client 1 core.repositoryformatversion
 '
 
-test_expect_success 'convert shallow clone to partial clone must fail with any extension' '
+test_expect_success 'convert shallow clone to partial clone succeeds with grandfathered extension' '
        rm -fr server client &&
        test_create_repo server &&
        test_commit -C server my_commit 1 &&
@@ -50,7 +50,20 @@ test_expect_success 'convert shallow clone to partial clone must fail with any e
        git clone --depth=1 "file://$(pwd)/server" client &&
        test_cmp_config -C client 0 core.repositoryformatversion &&
        git -C client config extensions.partialclone origin &&
-       test_must_fail git -C client fetch --unshallow --filter="blob:none"
+       git -C client fetch --unshallow --filter="blob:none"
+'
+
+test_expect_success 'convert shallow clone to partial clone must fail with unknown extension' '
+       rm -fr server client &&
+       test_create_repo server &&
+       test_commit -C server my_commit 1 &&
+       test_commit -C server my_commit2 1 &&
+       git clone --depth=1 "file://$(pwd)/server" client &&
+       test_cmp_config -C client 0 core.repositoryformatversion &&
+       git -C client config extensions.unknownExtension true &&
+       git -C client config extensions.partialclone origin &&
+       test_must_fail git -C client fetch --unshallow --filter="blob:none" 2>err &&
+       test_i18ngrep "unable to upgrade repository format from 0 to 1" err
 '
 
 test_expect_success 'missing reflog object, but promised by a commit, passes fsck' '


> The attached may be a less ambitious and less risky update for the
> upcoming release.  It is to be applied on top of the two-patch
> series from Derrick, and just marks the other "known and honored
> back then by mistake" extensions as OK to be there for upgrading.
> 
> Thoughts?  If people are happy with that, then we could apply and
> cut an -rc1 with it.  Or if we are OK with the "just special case
> worktreeconfig; other extensions may have the same issue but we
> haven't heard actual complaints so we will leave them untouched",
> then -rc1 can be done with just those two patches.

The "special case wortreeConfig" of my submission was maybe based
on an incorrect assumption that this is the only place where Git
itself set an extension.* config without _also_ updating the
core.repositoryFormatVersion config.

The error I made in my v1 is to warn on ALL extensions, not just
the ones that Git knows about. This new approach is a good middle
ground between my v1 and v2.

Of course, the _other_ option is to revert xl/upgrade-repo-format
from v2.28.0 and take our time resolving this issue during the
2.29 cycle. I'm not sure how disruptive that action would be.

> Now I do need to shift my attention to other topics in flight.

I appreciate you spending so much time on this! It's a tough
time to be noticing such a complicated situation that is not
easily testable from a single Git version, but across versions.

> 
>  setup.c | 27 ++++++++++++++++-----------
>  1 file changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/setup.c b/setup.c
> index 65270440a9..a072c76d05 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -456,27 +456,32 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
>  		data->version = git_config_int(var, value);
>  	else if (skip_prefix(var, "extensions.", &ext)) {
>  		/*
> -		 * record any known extensions here; otherwise,
> -		 * we fall through to recording it as unknown, and
> -		 * check_repository_format will complain
> +		 * Grandfather extensions that were known in 2.27 and
> +		 * were honored by mistake even in v0 repositories; it
> +		 * shoudn't be an error to upgrade v0 to v1 with them
> +		 * in the repository, as they couldn't have been used
> +		 * for incompatible purposes by the end user.
>  		 */
> -		int is_unallowed_extension = 1;
> +		int unallowed_in_v0 = 1;
>  
> -		if (!strcmp(ext, "noop"))
> -			;
> -		else if (!strcmp(ext, "preciousobjects"))
> +		if (!strcmp(ext, "noop")) {
> +			unallowed_in_v0 = 0;
> +		} else if (!strcmp(ext, "preciousobjects")) {
>  			data->precious_objects = git_config_bool(var, value);
> -		else if (!strcmp(ext, "partialclone")) {
> +			unallowed_in_v0 = 0;
> +		} else if (!strcmp(ext, "partialclone")) {
>  			if (!value)
>  				return config_error_nonbool(var);
>  			data->partial_clone = xstrdup(value);
> +			unallowed_in_v0 = 0;
>  		} else if (!strcmp(ext, "worktreeconfig")) {
>  			data->worktree_config = git_config_bool(var, value);
> -			is_unallowed_extension = 0;

Your previous diff had this comment, which I thought to be
helpful: 

+		/*
+		 * Extensions are added by more "} else if (...) {"
+		 * lines here, but do NOT mark them as allowed in v0
+		 * by copy-pasting without thinking.
+		 */

> -		} else
> +			unallowed_in_v0 = 0;
> +		} else {
>  			string_list_append(&data->unknown_extensions, ext);
> +		}
>  
> -		data->has_unallowed_extensions |= is_unallowed_extension;
> +		data->has_unallowed_extensions |= unallowed_in_v0;
>  	}
>  
>  	return read_worktree_config(var, value, vdata);

Thanks,
-Stolee
Junio C Hamano· Jul 15, 2020, 18:09 UTC · re: Derrick Stolee · lore

Re: [PATCH] setup: warn about un-enabled extensions

Derrick Stolee <stolee@gmail.com> writes:
Show 8 quoted lines
> Your previous diff had this comment, which I thought to be
> helpful: 
>
> +		/*
> +		 * Extensions are added by more "} else if (...) {"
> +		 * lines here, but do NOT mark them as allowed in v0
> +		 * by copy-pasting without thinking.
> +		 */

Yeah, but it felt somewhat strange to have it at the end of one entry, like this:

+			unallowed_in_v0 = 0;
 		} else if (!strcmp(ext, "worktreeconfig")) {
 			data->worktree_config = git_config_bool(var, value);
+			unallowed_in_v0 = 0;
+		/*
+		 * Extensions are added by more "} else if (...) {"
+		 * lines here, but do NOT mark them as allowed in v0
+		 * by copy-pasting without thinking.
+		 */
+		} else {
 			string_list_append(&data->unknown_extensions, ext);

In any case, I updated the comment in front of the if/else if/ cascade to essentially say the same thing, and with test updates this time.

Thanks.
-- >8 --
Subject: [PATCH] setup: grandfather other extensions that used to be honored by mistake

We special cased worktreeconfig extension to be OK to exist when the repository gets converted from v0 to v1 in an earlier commit, but other extenions were also honored by mistake in v0. Mark them the same way so that they won't interfere with the upgrading from v0 to v1.

A test in t0410 used to expect that presence of the extension.partialclone configuration variable to interfere, but that no longer is true.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 setup.c                  | 30 +++++++++++++++++++-----------
 t/t0410-partial-clone.sh | 18 ++++++++++++++++--
 2 files changed, 35 insertions(+), 13 deletions(-)
Show changes to 2 files +35 −13

setup.c, t/t0410-partial-clone.sh

diff --git a/setup.c b/setup.c
index 65270440a9..97292479d6 100644
--- a/setup.c
+++ b/setup.c
@@ -456,27 +456,35 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
 		data->version = git_config_int(var, value);
 	else if (skip_prefix(var, "extensions.", &ext)) {
 		/*
-		 * record any known extensions here; otherwise,
-		 * we fall through to recording it as unknown, and
-		 * check_repository_format will complain
+		 * Grandfather extensions that were known in 2.27 and
+		 * were honored by mistake even in v0 repositories; it
+		 * shoudn't be an error to upgrade v0 to v1 with them
+		 * in the repository, as they couldn't have been used
+		 * for incompatible purposes by the end user.
+		 *
+		 * When adding new extensions support in this if/elseif/...
+		 * cascade, do not mark them as allowed in v0!
 		 */
-		int is_unallowed_extension = 1;
+		int unallowed_in_v0 = 1;
 
-		if (!strcmp(ext, "noop"))
-			;
-		else if (!strcmp(ext, "preciousobjects"))
+		if (!strcmp(ext, "noop")) {
+			unallowed_in_v0 = 0;
+		} else if (!strcmp(ext, "preciousobjects")) {
 			data->precious_objects = git_config_bool(var, value);
-		else if (!strcmp(ext, "partialclone")) {
+			unallowed_in_v0 = 0;
+		} else if (!strcmp(ext, "partialclone")) {
 			if (!value)
 				return config_error_nonbool(var);
 			data->partial_clone = xstrdup(value);
+			unallowed_in_v0 = 0;
 		} else if (!strcmp(ext, "worktreeconfig")) {
 			data->worktree_config = git_config_bool(var, value);
-			is_unallowed_extension = 0;
-		} else
+			unallowed_in_v0 = 0;
+		} else {
 			string_list_append(&data->unknown_extensions, ext);
+		}
 
-		data->has_unallowed_extensions |= is_unallowed_extension;
+		data->has_unallowed_extensions |= unallowed_in_v0;
 	}
 
 	return read_worktree_config(var, value, vdata);
diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
index 463dc3a8be..e9674fc257 100755
--- a/t/t0410-partial-clone.sh
+++ b/t/t0410-partial-clone.sh
@@ -42,7 +42,7 @@ test_expect_success 'convert shallow clone to partial clone' '
 	test_cmp_config -C client 1 core.repositoryformatversion
 '
 
-test_expect_success 'convert shallow clone to partial clone must fail with any extension' '
+test_expect_success 'convert shallow clone to partial clone is OK with a grandfathered extension' '
 	rm -fr server client &&
 	test_create_repo server &&
 	test_commit -C server my_commit 1 &&
@@ -50,7 +50,21 @@ test_expect_success 'convert shallow clone to partial clone must fail with any e
 	git clone --depth=1 "file://$(pwd)/server" client &&
 	test_cmp_config -C client 0 core.repositoryformatversion &&
 	git -C client config extensions.partialclone origin &&
-	test_must_fail git -C client fetch --unshallow --filter="blob:none"
+	git -C client fetch --unshallow --filter="blob:none" &&
+	test_cmp_config -C client 1 core.repositoryformatversion
+'
+
+test_expect_success 'convert shallow clone to partial clone must fail with an unknown extension' '
+	rm -fr server client &&
+	test_create_repo server &&
+	test_commit -C server my_commit 1 &&
+	test_commit -C server my_commit2 1 &&
+	git clone --depth=1 "file://$(pwd)/server" client &&
+	test_cmp_config -C client 0 core.repositoryformatversion &&
+	git -C client config extensions.partialclone origin &&
+	git -C client config extensions.unknown true &&
+	test_must_fail git -C client fetch --unshallow --filter="blob:none" &&
+	test_cmp_config -C client 0 core.repositoryformatversion
 '
 
 test_expect_success 'missing reflog object, but promised by a commit, passes fsck' '
-- 
2.28.0-rc0
Derrick Stolee· Jul 15, 2020, 18:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

On 7/15/2020 2:09 PM, Junio C Hamano wrote:
Show 30 quoted lines
> Derrick Stolee <stolee@gmail.com> writes:
> 
>> Your previous diff had this comment, which I thought to be
>> helpful: 
>>
>> +		/*
>> +		 * Extensions are added by more "} else if (...) {"
>> +		 * lines here, but do NOT mark them as allowed in v0
>> +		 * by copy-pasting without thinking.
>> +		 */
> 
> Yeah, but it felt somewhat strange to have it at the end of one
> entry, like this:
> 
> +			unallowed_in_v0 = 0;
>  		} else if (!strcmp(ext, "worktreeconfig")) {
>  			data->worktree_config = git_config_bool(var, value);
> +			unallowed_in_v0 = 0;
> +		/*
> +		 * Extensions are added by more "} else if (...) {"
> +		 * lines here, but do NOT mark them as allowed in v0
> +		 * by copy-pasting without thinking.
> +		 */
> +		} else {
>  			string_list_append(&data->unknown_extensions, ext);
> 
> 
> In any case, I updated the comment in front of the if/else if/
> cascade to essentially say the same thing, and with test updates
> this time.
Thanks. I applied and tested this version. LGTM!
I'll also review Jonathan Nieder's patches when they arrive.

Thanks, -Stolee

Johannes Schindelin· Jul 15, 2020, 19:16 UTC · re: Derrick Stolee · lore

Re: [PATCH] setup: warn about un-enabled extensions

Hi,
On Wed, 15 Jul 2020, Derrick Stolee wrote:
Show 33 quoted lines
> On 7/15/2020 2:09 PM, Junio C Hamano wrote:
> > Derrick Stolee <stolee@gmail.com> writes:
> >
> >> Your previous diff had this comment, which I thought to be
> >> helpful:
> >>
> >> +		/*
> >> +		 * Extensions are added by more "} else if (...) {"
> >> +		 * lines here, but do NOT mark them as allowed in v0
> >> +		 * by copy-pasting without thinking.
> >> +		 */
> >
> > Yeah, but it felt somewhat strange to have it at the end of one
> > entry, like this:
> >
> > +			unallowed_in_v0 = 0;
> >  		} else if (!strcmp(ext, "worktreeconfig")) {
> >  			data->worktree_config = git_config_bool(var, value);
> > +			unallowed_in_v0 = 0;
> > +		/*
> > +		 * Extensions are added by more "} else if (...) {"
> > +		 * lines here, but do NOT mark them as allowed in v0
> > +		 * by copy-pasting without thinking.
> > +		 */
> > +		} else {
> >  			string_list_append(&data->unknown_extensions, ext);
> >
> >
> > In any case, I updated the comment in front of the if/else if/
> > cascade to essentially say the same thing, and with test updates
> > this time.
>
> Thanks. I applied and tested this version. LGTM!

Sorry for being slow at the party; I'd much rather deal with Git issues than with the paperwork I am fighting with.

Thank you for working on this, I am pretty happy with the state you whipped it into, but take that with a grain of salt, as my brain is moosh.

Ciao, Dscho

Junio C Hamano· Jul 15, 2020, 18:15 UTC · re: Derrick Stolee · lore

Re: [PATCH] setup: warn about un-enabled extensions

Derrick Stolee <stolee@gmail.com> writes:
> Of course, the _other_ option is to revert xl/upgrade-repo-format
> from v2.28.0 and take our time resolving this issue during the
> 2.29 cycle. I'm not sure how disruptive that action would be.
Yes, that is becoming very much tempting at this point, isn't it?

In any case, I've pushed out 'seen' with the "these extensions that used to be honored in v0 won't interfere with repository upgrade" patch I sent earlier, and I am hoping that it would be a reasonable middle ground that won't regress things for users while making sure we do not honor random future extensions by mistake.

Johannes Schindelin· Jul 15, 2020, 19:21 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

Hi Junio,
On Wed, 15 Jul 2020, Junio C Hamano wrote:
Show 7 quoted lines
> Derrick Stolee <stolee@gmail.com> writes:
>
> > Of course, the _other_ option is to revert xl/upgrade-repo-format
> > from v2.28.0 and take our time resolving this issue during the
> > 2.29 cycle. I'm not sure how disruptive that action would be.
>
> Yes, that is becoming very much tempting at this point, isn't it?
It did cross my mind, too.
Show 5 quoted lines
> In any case, I've pushed out 'seen' with the "these extensions that
> used to be honored in v0 won't interfere with repository upgrade"
> patch I sent earlier, and I am hoping that it would be a reasonable
> middle ground that won't regress things for users while making sure
> we do not honor random future extensions by mistake.

Given that we still have -rc1 and -rc2 to make sure that things work, and given that your patch on top of Stolee's two patches looks like it is Doing The Best We Can Do, I am optimistic that your reasonable middle ground is the best way forward.

Thanks, Dscho

Jonathan Nieder· Jul 15, 2020, 18:20 UTC · re: Junio C Hamano · lore

Re: [PATCH] setup: warn about un-enabled extensions

Hi,
Junio C Hamano wrote:
> It seems that there is no quick concensus to go with your "different
> endgame" and worse yet it seems nobody is interested in helping
> much.
Sorry for the delay.  I do want to look at this this afternoon.
[...]
Show 5 quoted lines
> I'll shift my attention to other topics that should be in the
> release for the rest of the day, but am pessimistic that I can tag
> the -rc1 today, which won't happen until we at least have a
> concensus on what to do with the (apparent) regression due to the
> "upgrade repository version" topic.

Ah, I hadn't realized an -rc1 tomorrow instead of today was on the table. ;-)

I'll do what I can (in other words, expect a patch from me; but also, I am very interested in analysis, proposed patches, etc from others so that we can end up wit ha good fix with the solution space well explored).

Thanks, Jonathan

Junio C Hamano· Jul 16, 2020, 02:06 UTC · re: Jonathan Nieder · lore

Re: [PATCH] setup: warn about un-enabled extensions

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 8 quoted lines
>> I'll shift my attention to other topics that should be in the
>> release for the rest of the day, but am pessimistic that I can tag
>> the -rc1 today, which won't happen until we at least have a
>> concensus on what to do with the (apparent) regression due to the
>> "upgrade repository version" topic.
>
> Ah, I hadn't realized an -rc1 tomorrow instead of today was on the
> table. ;-)

It could be delayed even more if we do not have a good solution agreed upon.

> I'll do what I can (in other words, expect a patch from me; but also,
> I am very interested in analysis, proposed patches, etc from others so
> that we can end up wit ha good fix with the solution space well
> explored).
Yup, that's the spirit.  Thanks!
Jonathan Nieder· Jul 16, 2020, 06:20 UTC · re: Junio C Hamano · lore

[PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions)

Junio C Hamano wrote:
> Here is my quick attempt to see how far we can go with the
> "different endgame" approach, to be applied on top of those two
> patches.
Apologies again for the delay.

Here are patches implementing the minimal fix that I'd recommend. These apply against "master" without requiring any other patches as prerequisites. Thoughts?

Jonathan Nieder (2):
  Revert "check_repository_format_gently(): refuse extensions for old
    repositories"
  repository: allow repository format upgrade with extensions
 cache.h                  |  1 -
 setup.c                  | 24 ++++++++++--------------
 t/t0410-partial-clone.sh | 15 +++++++++++++--
 3 files changed, 23 insertions(+), 17 deletions(-)
Jonathan Nieder· Jul 16, 2020, 06:24 UTC · re: Jonathan Nieder · lore

[PATCH 1/2] Revert "check_repository_format_gently(): refuse extensions for old repositories"

This reverts commit 14c7fa269e42df4133edd9ae7763b678ed6594cd.

The core.repositoryFormatVersion field was introduced in ab9cb76f661 (Repository format version check., 2005-11-25), providing a welcome bit of forward compatibility, thanks to some welcome analysis by Martin Atukunda. The semantics are simple: a repository with core.repositoryFormatVersion set to 0 should be comprehensible by all Git implementations in active use; and Git implementations should error out early instead of trying to act on Git repositories with higher core.repositoryFormatVersion values representing new formats that they do not understand.

A new repository format did not need to be defined until 00a09d57eb8 (introduce "extensions" form of core.repositoryformatversion, 2015-06-23). This provided a finer-grained extension mechanism for Git repositories. In a repository with core.repositoryFormatVersion set to 1, Git implementations can act on "extensions.*" settings that modify how a repository is interpreted. In repository format version 1, unrecognized extensions settings cause Git to error out.

What happens if a user sets an extension setting but forgets to increase the repository format version to 1? The extension settings were still recognized in that case; worse, unrecognized extensions settings do *not* cause Git to error out. So combining repository format version 0 with extensions settings produces in some sense the worst of both worlds.

To improve that situation, since 14c7fa269e4 (check_repository_format_gently(): refuse extensions for old repositories, 2020-06-05) Git instead ignores extensions in v0 mode. This way, v0 repositories get the historical (pre-2015) behavior and maintain compatibility with Git implementations that do not know about the v1 format. Unfortunately, users had been using this sort of configuration and this behavior change came to many as a surprise:

- users of "git config --worktree" that had followed its advice
  to enable extensions.worktreeConfig (without also increasing the
  repository format version) would find their worktree configuration
  no longer taking effect
- tools such as copybara[*] that had set extensions.partialClone in
  existing repositories (without also increasing the repository format
  version) would find that setting no longer taking effect

The behavior introduced in 14c7fa269e4 might be a good behavior if we were traveling back in time to 2015, but we're far too late. For some reason I thought that it was what had been originally implemented and that it had regressed. Apologies for not doing my research when 14c7fa269e4 was under development.

Let's return to the behavior we've had since 2015: always act on extensions.* settings, regardless of repository format version. While we're here, include some tests to describe the effect on the "upgrade repository version" code path.

[*] https://github.com/google/copybara/commit/ca76c0b1e13c4e36448d12c2aba4a5d9d98fb6e7
Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 setup.c                  | 12 +++---------
 t/t0410-partial-clone.sh | 15 +++++++++++++--
 2 files changed, 16 insertions(+), 11 deletions(-)
Show changes to 2 files +16 −11

setup.c, t/t0410-partial-clone.sh

diff --git a/setup.c b/setup.c
index dbac2eabe8f..87bf0112cf3 100644
--- a/setup.c
+++ b/setup.c
@@ -507,15 +507,9 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
 		die("%s", err.buf);
 	}
 
-	if (candidate->version >= 1) {
-		repository_format_precious_objects = candidate->precious_objects;
-		set_repository_format_partial_clone(candidate->partial_clone);
-		repository_format_worktree_config = candidate->worktree_config;
-	} else {
-		repository_format_precious_objects = 0;
-		set_repository_format_partial_clone(NULL);
-		repository_format_worktree_config = 0;
-	}
+	repository_format_precious_objects = candidate->precious_objects;
+	set_repository_format_partial_clone(candidate->partial_clone);
+	repository_format_worktree_config = candidate->worktree_config;
 	string_list_clear(&candidate->unknown_extensions, 0);
 
 	if (repository_format_worktree_config) {
diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
index 463dc3a8be0..51d1eba6050 100755
--- a/t/t0410-partial-clone.sh
+++ b/t/t0410-partial-clone.sh
@@ -42,14 +42,25 @@ test_expect_success 'convert shallow clone to partial clone' '
 	test_cmp_config -C client 1 core.repositoryformatversion
 '
 
-test_expect_success 'convert shallow clone to partial clone must fail with any extension' '
+test_expect_success 'converting to partial clone fails with noop extension' '
 	rm -fr server client &&
 	test_create_repo server &&
 	test_commit -C server my_commit 1 &&
 	test_commit -C server my_commit2 1 &&
 	git clone --depth=1 "file://$(pwd)/server" client &&
 	test_cmp_config -C client 0 core.repositoryformatversion &&
-	git -C client config extensions.partialclone origin &&
+	git -C client config extensions.noop true &&
+	test_must_fail git -C client fetch --unshallow --filter="blob:none"
+'
+
+test_expect_success 'converting to partial clone fails with unrecognized extension' '
+	rm -fr server client &&
+	test_create_repo server &&
+	test_commit -C server my_commit 1 &&
+	test_commit -C server my_commit2 1 &&
+	git clone --depth=1 "file://$(pwd)/server" client &&
+	test_cmp_config -C client 0 core.repositoryformatversion &&
+	git -C client config extensions.nonsense true &&
 	test_must_fail git -C client fetch --unshallow --filter="blob:none"
 '
 
-- 
2.28.0.rc0.105.gf9edc3c819
Jeff King· Jul 16, 2020, 10:56 UTC · re: Jonathan Nieder · lore

Re: [PATCH 1/2] Revert "check_repository_format_gently(): refuse extensions for old repositories"

On Wed, Jul 15, 2020 at 11:24:29PM -0700, Jonathan Nieder wrote:
Show 5 quoted lines
> The behavior introduced in 14c7fa269e4 might be a good behavior if we
> were traveling back in time to 2015, but we're far too late.  For some
> reason I thought that it was what had been originally implemented and
> that it had regressed.  Apologies for not doing my research when
> 14c7fa269e4 was under development.

Thanks for a good summary of the situation. I agree that the current (well, pre-14c7fa269e4) behavior is a bug (mine) from 2015, and we probably have to accept that state of affairs to some degree in order to avoid breaking existing cases.

It is unfortunate that this means that somebody with version=0 and extensions.preciousObjects is in danger of running a pre-2015 version of Git and having that extension totally ignored, which could be a data-safety issue. But the farther we get from 2015 the less likely that is to be a problem (and the more likely somebody is to be depending on the current behavior of v0+preciousObjects).

> Let's return to the behavior we've had since 2015: always act on
> extensions.* settings, regardless of repository format version.  While
> we're here, include some tests to describe the effect on the "upgrade
> repository version" code path.
So this makes sense to me as a first step.
-Peff
Jonathan Nieder· Jul 16, 2020, 06:28 UTC · re: Jonathan Nieder · lore

[PATCH 2/2] repository: allow repository format upgrade with extensions

Now that we officially permit repository extensions in repository format v0, permit upgrading a repository with extensions from v0 to v1 as well.

For example, this means a repository where the user has set "extensions.preciousObjects" can use "git fetch --filter=blob:none origin" to upgrade the repository to use v1 and the partial clone extension.

To avoid mistakes, continue to forbid repository format upgrades in v0 repositories with an unrecognized extension. This way, a v0 user using a misspelled extension field gets a chance to correct the mistake before updating to the less forgiving v1 format.

While we're here, make the error message for failure to upgrade the repository format a bit shorter, and present it as an error, not a warning.

Reported-by: Huan Huan Chen <huanhuanchen@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Apologies again for the trouble, and thanks for your patient help.
 cache.h                  |  1 -
 setup.c                  | 12 +++++++-----
 t/t0410-partial-clone.sh |  4 ++--
 3 files changed, 9 insertions(+), 8 deletions(-)
Show changes to 3 files +9 −8

cache.h, setup.c, t/t0410-partial-clone.sh

diff --git a/cache.h b/cache.h
index 126ec56c7f3..654426460cc 100644
--- a/cache.h
+++ b/cache.h
@@ -1042,7 +1042,6 @@ struct repository_format {
 	int worktree_config;
 	int is_bare;
 	int hash_algo;
-	int has_extensions;
 	char *work_tree;
 	struct string_list unknown_extensions;
 };
diff --git a/setup.c b/setup.c
index 87bf0112cf3..3a81307602e 100644
--- a/setup.c
+++ b/setup.c
@@ -455,7 +455,6 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
 	if (strcmp(var, "core.repositoryformatversion") == 0)
 		data->version = git_config_int(var, value);
 	else if (skip_prefix(var, "extensions.", &ext)) {
-		data->has_extensions = 1;
 		/*
 		 * record any known extensions here; otherwise,
 		 * we fall through to recording it as unknown, and
@@ -553,13 +552,16 @@ int upgrade_repository_format(int target_version)
 	if (repo_fmt.version >= target_version)
 		return 0;
 
-	if (verify_repository_format(&repo_fmt, &err) < 0 ||
-	    (!repo_fmt.version && repo_fmt.has_extensions)) {
-		warning("unable to upgrade repository format from %d to %d: %s",
-			repo_fmt.version, target_version, err.buf);
+	if (verify_repository_format(&repo_fmt, &err) < 0) {
+		error("cannot upgrade repository format from %d to %d: %s",
+		      repo_fmt.version, target_version, err.buf);
 		strbuf_release(&err);
 		return -1;
 	}
+	if (!repo_fmt.version && repo_fmt.unknown_extensions.nr)
+		return error("cannot upgrade repository format: "
+			     "unknown extension %s",
+			     repo_fmt.unknown_extensions.items[0].string);
 
 	strbuf_addf(&repo_version, "%d", target_version);
 	git_config_set("core.repositoryformatversion", repo_version.buf);
diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
index 51d1eba6050..6aa0f313bdd 100755
--- a/t/t0410-partial-clone.sh
+++ b/t/t0410-partial-clone.sh
@@ -42,7 +42,7 @@ test_expect_success 'convert shallow clone to partial clone' '
 	test_cmp_config -C client 1 core.repositoryformatversion
 '
 
-test_expect_success 'converting to partial clone fails with noop extension' '
+test_expect_success 'convert to partial clone with noop extension' '
 	rm -fr server client &&
 	test_create_repo server &&
 	test_commit -C server my_commit 1 &&
@@ -50,7 +50,7 @@ test_expect_success 'converting to partial clone fails with noop extension' '
 	git clone --depth=1 "file://$(pwd)/server" client &&
 	test_cmp_config -C client 0 core.repositoryformatversion &&
 	git -C client config extensions.noop true &&
-	test_must_fail git -C client fetch --unshallow --filter="blob:none"
+	git -C client fetch --unshallow --filter="blob:none"
 '
 
 test_expect_success 'converting to partial clone fails with unrecognized extension' '
-- 
2.28.0.rc0.105.gf9edc3c819
Junio C Hamano· Jul 16, 2020, 07:01 UTC · re: Jonathan Nieder · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 13 quoted lines
> Now that we officially permit repository extensions in repository
> format v0, permit upgrading a repository with extensions from v0 to v1
> as well.
>
> For example, this means a repository where the user has set
> "extensions.preciousObjects" can use "git fetch --filter=blob:none
> origin" to upgrade the repository to use v1 and the partial clone
> extension.
>
> To avoid mistakes, continue to forbid repository format upgrades in v0
> repositories with an unrecognized extension.  This way, a v0 user
> using a misspelled extension field gets a chance to correct the
> mistake before updating to the less forgiving v1 format.

This needs to be managed carefully. When the next extension is added to the codebase, that extension may be "known" to Git, but I do not think it is a good idea to honor it in v0 repository, or allow upgrading v0 repository to v1 with such an extension that weren't "known" to Git. For example, a topic in flight adds objectformat extension and I do not think it should be honored in v0 repository.

Having said that, the approach is OK for now at the tip of tonight's master, but the point is "known" vs "unknown" must be fixed right with some means. E.g. tell people to throw the "new" extensions to the list of "unknown extensions" in check_repo_format() when they add new ones, or something.

Thanks.
Show 29 quoted lines
> +	if (!repo_fmt.version && repo_fmt.unknown_extensions.nr)
> +		return error("cannot upgrade repository format: "
> +			     "unknown extension %s",
> +			     repo_fmt.unknown_extensions.items[0].string);
>  
>  	strbuf_addf(&repo_version, "%d", target_version);
>  	git_config_set("core.repositoryformatversion", repo_version.buf);
> diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
> index 51d1eba6050..6aa0f313bdd 100755
> --- a/t/t0410-partial-clone.sh
> +++ b/t/t0410-partial-clone.sh
> @@ -42,7 +42,7 @@ test_expect_success 'convert shallow clone to partial clone' '
>  	test_cmp_config -C client 1 core.repositoryformatversion
>  '
>  
> -test_expect_success 'converting to partial clone fails with noop extension' '
> +test_expect_success 'convert to partial clone with noop extension' '
>  	rm -fr server client &&
>  	test_create_repo server &&
>  	test_commit -C server my_commit 1 &&
> @@ -50,7 +50,7 @@ test_expect_success 'converting to partial clone fails with noop extension' '
>  	git clone --depth=1 "file://$(pwd)/server" client &&
>  	test_cmp_config -C client 0 core.repositoryformatversion &&
>  	git -C client config extensions.noop true &&
> -	test_must_fail git -C client fetch --unshallow --filter="blob:none"
> +	git -C client fetch --unshallow --filter="blob:none"
>  '
>  
>  test_expect_success 'converting to partial clone fails with unrecognized extension' '
Jeff King· Jul 16, 2020, 11:00 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On Thu, Jul 16, 2020 at 12:01:09AM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> > To avoid mistakes, continue to forbid repository format upgrades in v0
> > repositories with an unrecognized extension.  This way, a v0 user
> > using a misspelled extension field gets a chance to correct the
> > mistake before updating to the less forgiving v1 format.
> 
> This needs to be managed carefully.  When the next extension is
> added to the codebase, that extension may be "known" to Git, but I
> do not think it is a good idea to honor it in v0 repository, or
> allow upgrading v0 repository to v1 with such an extension that
> weren't "known" to Git.  For example, a topic in flight adds
> objectformat extension and I do not think it should be honored in v0
> repository.
> 
> Having said that, the approach is OK for now at the tip of tonight's
> master, but the point is "known" vs "unknown" must be fixed right
> with some means.  E.g. tell people to throw the "new" extensions to
> the list of "unknown extensions" in check_repo_format() when they
> add new ones, or something.

Yeah, I agree with this line of reasoning. I'd prefer to see it addressed now, so that we don't have to remember to do anything later. I.e., for this patch to put the existing known extensions into the "good" list for v0, locking it into place forever, and leaving the objectformat topic with nothing particular it needs to do.

But in the name of -rc1 expediency, I'm also OK moving forward with this for now.

-Peff
Jeff King· Jul 16, 2020, 12:25 UTC · re: Jeff King · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On Thu, Jul 16, 2020 at 07:00:08AM -0400, Jeff King wrote:
Show 27 quoted lines
> > > To avoid mistakes, continue to forbid repository format upgrades in v0
> > > repositories with an unrecognized extension.  This way, a v0 user
> > > using a misspelled extension field gets a chance to correct the
> > > mistake before updating to the less forgiving v1 format.
> > 
> > This needs to be managed carefully.  When the next extension is
> > added to the codebase, that extension may be "known" to Git, but I
> > do not think it is a good idea to honor it in v0 repository, or
> > allow upgrading v0 repository to v1 with such an extension that
> > weren't "known" to Git.  For example, a topic in flight adds
> > objectformat extension and I do not think it should be honored in v0
> > repository.
> > 
> > Having said that, the approach is OK for now at the tip of tonight's
> > master, but the point is "known" vs "unknown" must be fixed right
> > with some means.  E.g. tell people to throw the "new" extensions to
> > the list of "unknown extensions" in check_repo_format() when they
> > add new ones, or something.
> 
> Yeah, I agree with this line of reasoning. I'd prefer to see it
> addressed now, so that we don't have to remember to do anything later.
> I.e., for this patch to put the existing known extensions into the
> "good" list for v0, locking it into place forever, and leaving the
> objectformat topic with nothing particular it needs to do.
> 
> But in the name of -rc1 expediency, I'm also OK moving forward with this
> for now.

Hmm, this is actually a bit trickier than I expected because of the way the code is written. It's much easier to complain about extensions in a v0 repository than it is to ignore them. But I'm not sure if that isn't the right way to go anyway.

The patch I came up with is below (and goes on top of Jonathan's). Even if we decide this is the right direction, it can definitely happen post-v2.28.

-- >8 --
Subject: verify_repository_format(): complain about new extensions in v0 repo

We made the mistake in the past of respecting extensions.* even when the repository format version was set to 0. This is bad because forgetting to bump the repository version means that older versions of Git (which do not know about our extensions) won't complain. I.e., it's not a problem in itself, but it means your repository is in a state which does not give you the protection you think you're getting from older versions.

For compatibility reasons, we are stuck with that decision for existing extensions. However, we'd prefer not to extend the damage further. We can do that by catching any newly-added extensions and complaining about the repository format.

Note that this is a pretty heavy hammer: we'll refuse to work with the repository at all. A lesser option would be to ignore (possibly with a warning) any new extensions. But because of the way the extensions are handled, that puts the burden on each new extension that is added to remember to "undo" itself (because they are handled before we know for sure whether we are in a v1 repo or not, since we don't insist on a particular ordering of config entries).

So one option would be to rewrite that handling to record any new extensions (and their values) during the config parse, and then only after proceed to handle new ones only if we're in a v1 repository. But I'm not sure if it's worth the trouble:

  - ignoring extensions is likely to end up with broken results anyway
    (e.g., ignoring a proposed objectformat extension means parsing any
    object data is likely to encounter errors)
  - this is a sign that whatever tool wrote the extension field is
    broken. We may be better off notifying immediately and forcefully so
    that such tools don't even appear to work accidentally.

The only downside is that fixing the istuation is a little tricky, because programs like "git config" won't want to work with the repository. But:

  git config --file=.git/config core.repositoryformatversion 1
should still suffice.
Signed-off-by: Jeff King <peff@peff.net>
---
 cache.h                 |  2 +
 setup.c                 | 96 ++++++++++++++++++++++++++++++++++-------
 t/t1302-repo-version.sh |  3 ++
 3 files changed, 85 insertions(+), 16 deletions(-)
Show changes to 3 files +85 −16

cache.h, setup.c, t/t1302-repo-version.sh

diff --git a/cache.h b/cache.h
index 654426460c..0290849c19 100644
--- a/cache.h
+++ b/cache.h
@@ -1044,6 +1044,7 @@ struct repository_format {
 	int hash_algo;
 	char *work_tree;
 	struct string_list unknown_extensions;
+	struct string_list v1_only_extensions;
 };
 
 /*
@@ -1057,6 +1058,7 @@ struct repository_format {
 	.is_bare = -1, \
 	.hash_algo = GIT_HASH_SHA1, \
 	.unknown_extensions = STRING_LIST_INIT_DUP, \
+	.v1_only_extensions = STRING_LIST_INIT_DUP, \
 }
 
 /*
diff --git a/setup.c b/setup.c
index 3a81307602..c1480b2b60 100644
--- a/setup.c
+++ b/setup.c
@@ -447,6 +447,54 @@ static int read_worktree_config(const char *var, const char *value, void *vdata)
 	return 0;
 }
 
+enum extension_result {
+	EXTENSION_ERROR = -1, /* compatible with error(), etc */
+	EXTENSION_UNKNOWN = 0,
+	EXTENSION_OK = 1
+};
+
+/*
+ * Do not add new extensions to this function. It handles extensions which are
+ * respected even in v0-format repositories for historical compatibility.
+ */
+enum extension_result handle_extension_v0(const char *var,
+					  const char *value,
+					  const char *ext,
+					  struct repository_format *data)
+{
+		if (!strcmp(ext, "noop")) {
+			return EXTENSION_OK;
+		} else if (!strcmp(ext, "preciousobjects")) {
+			data->precious_objects = git_config_bool(var, value);
+			return EXTENSION_OK;
+		} else if (!strcmp(ext, "partialclone")) {
+			if (!value)
+				return config_error_nonbool(var);
+			data->partial_clone = xstrdup(value);
+			return EXTENSION_OK;
+		} else if (!strcmp(ext, "worktreeconfig")) {
+			data->worktree_config = git_config_bool(var, value);
+			return EXTENSION_OK;
+		}
+
+		return EXTENSION_UNKNOWN;
+}
+
+/*
+ * Record any new extensions in this function.
+ */
+enum extension_result handle_extension(const char *var,
+				       const char *value,
+				       const char *ext,
+				       struct repository_format *data)
+{
+	if (!strcmp(ext, "noop-v1")) {
+		return EXTENSION_OK;
+	}
+
+	return EXTENSION_UNKNOWN;
+}
+
 static int check_repo_format(const char *var, const char *value, void *vdata)
 {
 	struct repository_format *data = vdata;
@@ -455,23 +503,25 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
 	if (strcmp(var, "core.repositoryformatversion") == 0)
 		data->version = git_config_int(var, value);
 	else if (skip_prefix(var, "extensions.", &ext)) {
-		/*
-		 * record any known extensions here; otherwise,
-		 * we fall through to recording it as unknown, and
-		 * check_repository_format will complain
-		 */
-		if (!strcmp(ext, "noop"))
-			;
-		else if (!strcmp(ext, "preciousobjects"))
-			data->precious_objects = git_config_bool(var, value);
-		else if (!strcmp(ext, "partialclone")) {
-			if (!value)
-				return config_error_nonbool(var);
-			data->partial_clone = xstrdup(value);
-		} else if (!strcmp(ext, "worktreeconfig"))
-			data->worktree_config = git_config_bool(var, value);
-		else
+		switch (handle_extension_v0(var, value, ext, data)) {
+		case EXTENSION_ERROR:
+			return -1;
+		case EXTENSION_OK:
+			return 0;
+		case EXTENSION_UNKNOWN:
+			break;
+		}
+
+		switch (handle_extension(var, value, ext, data)) {
+		case EXTENSION_ERROR:
+			return -1;
+		case EXTENSION_OK:
+			string_list_append(&data->v1_only_extensions, ext);
+			return 0;
+		case EXTENSION_UNKNOWN:
 			string_list_append(&data->unknown_extensions, ext);
+			return 0;
+		}
 	}
 
 	return read_worktree_config(var, value, vdata);
@@ -510,6 +560,7 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
 	set_repository_format_partial_clone(candidate->partial_clone);
 	repository_format_worktree_config = candidate->worktree_config;
 	string_list_clear(&candidate->unknown_extensions, 0);
+	string_list_clear(&candidate->v1_only_extensions, 0);
 
 	if (repository_format_worktree_config) {
 		/*
@@ -588,6 +639,7 @@ int read_repository_format(struct repository_format *format, const char *path)
 void clear_repository_format(struct repository_format *format)
 {
 	string_list_clear(&format->unknown_extensions, 0);
+	string_list_clear(&format->v1_only_extensions, 0);
 	free(format->work_tree);
 	free(format->partial_clone);
 	init_repository_format(format);
@@ -613,6 +665,18 @@ int verify_repository_format(const struct repository_format *format,
 		return -1;
 	}
 
+	if (format->version == 0 && format->v1_only_extensions.nr) {
+		int i;
+
+		strbuf_addstr(err,
+			      _("repo version is 0, but v1-only extensions found:"));
+
+		for (i = 0; i < format->v1_only_extensions.nr; i++)
+			strbuf_addf(err, "\n\t%s",
+				    format->v1_only_extensions.items[i].string);
+		return -1;
+	}
+
 	return 0;
 }
 
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index d60c042ce8..0acabb6d11 100755
--- a/t/t1302-repo-version.sh
+++ b/t/t1302-repo-version.sh
@@ -87,6 +87,9 @@ allow 1
 allow 1 noop
 abort 1 no-such-extension
 allow 0 no-such-extension
+allow 0 noop
+abort 0 noop-v1
+allow 1 noop-v1
 EOF
 
 test_expect_success 'precious-objects allowed' '
-- 
2.28.0.rc0.424.g7d08728e23
Derrick Stolee· Jul 16, 2020, 12:53 UTC · re: Jeff King · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On 7/16/2020 8:25 AM, Jeff King wrote:
Show 77 quoted lines
> On Thu, Jul 16, 2020 at 07:00:08AM -0400, Jeff King wrote:
> 
>>>> To avoid mistakes, continue to forbid repository format upgrades in v0
>>>> repositories with an unrecognized extension.  This way, a v0 user
>>>> using a misspelled extension field gets a chance to correct the
>>>> mistake before updating to the less forgiving v1 format.
>>>
>>> This needs to be managed carefully.  When the next extension is
>>> added to the codebase, that extension may be "known" to Git, but I
>>> do not think it is a good idea to honor it in v0 repository, or
>>> allow upgrading v0 repository to v1 with such an extension that
>>> weren't "known" to Git.  For example, a topic in flight adds
>>> objectformat extension and I do not think it should be honored in v0
>>> repository.
>>>
>>> Having said that, the approach is OK for now at the tip of tonight's
>>> master, but the point is "known" vs "unknown" must be fixed right
>>> with some means.  E.g. tell people to throw the "new" extensions to
>>> the list of "unknown extensions" in check_repo_format() when they
>>> add new ones, or something.
>>
>> Yeah, I agree with this line of reasoning. I'd prefer to see it
>> addressed now, so that we don't have to remember to do anything later.
>> I.e., for this patch to put the existing known extensions into the
>> "good" list for v0, locking it into place forever, and leaving the
>> objectformat topic with nothing particular it needs to do.
>>
>> But in the name of -rc1 expediency, I'm also OK moving forward with this
>> for now.
> 
> Hmm, this is actually a bit trickier than I expected because of the way
> the code is written. It's much easier to complain about extensions in a
> v0 repository than it is to ignore them. But I'm not sure if that isn't
> the right way to go anyway.
> 
> The patch I came up with is below (and goes on top of Jonathan's). Even
> if we decide this is the right direction, it can definitely happen
> post-v2.28.
> 
> -- >8 --
> Subject: verify_repository_format(): complain about new extensions in v0 repo
> 
> We made the mistake in the past of respecting extensions.* even when the
> repository format version was set to 0. This is bad because forgetting
> to bump the repository version means that older versions of Git (which
> do not know about our extensions) won't complain. I.e., it's not a
> problem in itself, but it means your repository is in a state which does
> not give you the protection you think you're getting from older
> versions.
> 
> For compatibility reasons, we are stuck with that decision for existing
> extensions. However, we'd prefer not to extend the damage further. We
> can do that by catching any newly-added extensions and complaining about
> the repository format.
> 
> Note that this is a pretty heavy hammer: we'll refuse to work with the
> repository at all. A lesser option would be to ignore (possibly with a
> warning) any new extensions. But because of the way the extensions are
> handled, that puts the burden on each new extension that is added to
> remember to "undo" itself (because they are handled before we know
> for sure whether we are in a v1 repo or not, since we don't insist on a
> particular ordering of config entries).
> 
> So one option would be to rewrite that handling to record any new
> extensions (and their values) during the config parse, and then only
> after proceed to handle new ones only if we're in a v1 repository. But
> I'm not sure if it's worth the trouble:
> 
>   - ignoring extensions is likely to end up with broken results anyway
>     (e.g., ignoring a proposed objectformat extension means parsing any
>     object data is likely to encounter errors)
> 
>   - this is a sign that whatever tool wrote the extension field is
>     broken. We may be better off notifying immediately and forcefully so
>     that such tools don't even appear to work accidentally.
> 
> The only downside is that fixing the istuation is a little tricky,
s/istuation/situation
Show 56 quoted lines
> because programs like "git config" won't want to work with the
> repository. But:
> 
>   git config --file=.git/config core.repositoryformatversion 1
> 
> should still suffice.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  cache.h                 |  2 +
>  setup.c                 | 96 ++++++++++++++++++++++++++++++++++-------
>  t/t1302-repo-version.sh |  3 ++
>  3 files changed, 85 insertions(+), 16 deletions(-)
> 
> diff --git a/cache.h b/cache.h
> index 654426460c..0290849c19 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1044,6 +1044,7 @@ struct repository_format {
>  	int hash_algo;
>  	char *work_tree;
>  	struct string_list unknown_extensions;
> +	struct string_list v1_only_extensions;
>  };
>  
>  /*
> @@ -1057,6 +1058,7 @@ struct repository_format {
>  	.is_bare = -1, \
>  	.hash_algo = GIT_HASH_SHA1, \
>  	.unknown_extensions = STRING_LIST_INIT_DUP, \
> +	.v1_only_extensions = STRING_LIST_INIT_DUP, \
>  }
>  
>  /*
> diff --git a/setup.c b/setup.c
> index 3a81307602..c1480b2b60 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -447,6 +447,54 @@ static int read_worktree_config(const char *var, const char *value, void *vdata)
>  	return 0;
>  }
>  
> +enum extension_result {
> +	EXTENSION_ERROR = -1, /* compatible with error(), etc */
> +	EXTENSION_UNKNOWN = 0,
> +	EXTENSION_OK = 1
> +};
> +
> +/*
> + * Do not add new extensions to this function. It handles extensions which are
> + * respected even in v0-format repositories for historical compatibility.
> + */
> +enum extension_result handle_extension_v0(const char *var,
> +					  const char *value,
> +					  const char *ext,
> +					  struct repository_format *data)
...
Show 7 quoted lines
> +/*
> + * Record any new extensions in this function.
> + */
> +enum extension_result handle_extension(const char *var,
> +				       const char *value,
> +				       const char *ext,
> +				       struct repository_format *data)

I like the split between these two methods to make it really clear the difference between "v0" and "v1".

Show 5 quoted lines
>  	struct repository_format *data = vdata;
> @@ -455,23 +503,25 @@ static int check_repo_format(const char *var, const char *value, void *vdata)
>  	if (strcmp(var, "core.repositoryformatversion") == 0)
>  		data->version = git_config_int(var, value);
>  	else if (skip_prefix(var, "extensions.", &ext)) {
...
Show 20 quoted lines
> +		switch (handle_extension_v0(var, value, ext, data)) {
> +		case EXTENSION_ERROR:
> +			return -1;
> +		case EXTENSION_OK:
> +			return 0;
> +		case EXTENSION_UNKNOWN:
> +			break;
> +		}
> +
> +		switch (handle_extension(var, value, ext, data)) {
> +		case EXTENSION_ERROR:
> +			return -1;
> +		case EXTENSION_OK:
> +			string_list_append(&data->v1_only_extensions, ext);
> +			return 0;
> +		case EXTENSION_UNKNOWN:
>  			string_list_append(&data->unknown_extensions, ext);
> +			return 0;
> +		}
>  	}
And it makes this loop much cleaner.
Show 30 quoted lines
> @@ -613,6 +665,18 @@ int verify_repository_format(const struct repository_format *format,
>  		return -1;
>  	}
>  
> +	if (format->version == 0 && format->v1_only_extensions.nr) {
> +		int i;
> +
> +		strbuf_addstr(err,
> +			      _("repo version is 0, but v1-only extensions found:"));
> +
> +		for (i = 0; i < format->v1_only_extensions.nr; i++)
> +			strbuf_addf(err, "\n\t%s",
> +				    format->v1_only_extensions.items[i].string);
> +		return -1;
> +	}
> +
>  	return 0;
>  }
>  
> diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
> index d60c042ce8..0acabb6d11 100755
> --- a/t/t1302-repo-version.sh
> +++ b/t/t1302-repo-version.sh
> @@ -87,6 +87,9 @@ allow 1
>  allow 1 noop
>  abort 1 no-such-extension
>  allow 0 no-such-extension
> +allow 0 noop
> +abort 0 noop-v1
> +allow 1 noop-v1
LGTM.

Thanks, -Stolee

Junio C Hamano· Jul 16, 2020, 16:32 UTC · re: Jeff King · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> Hmm, this is actually a bit trickier than I expected because of the way
> the code is written. It's much easier to complain about extensions in a
> v0 repository than it is to ignore them. But I'm not sure if that isn't
> the right way to go anyway.
>
> The patch I came up with is below (and goes on top of Jonathan's). Even
> if we decide this is the right direction, it can definitely happen
> post-v2.28.

It must happen already in 'seen' if we want to keep bc/sha-2-part-3 with us, though ;-)

> So one option would be to rewrite that handling to record any new
> extensions (and their values) during the config parse, and then only
> after proceed to handle new ones only if we're in a v1 repository.

I do not think it would be too bad for read_repository_format() to call git_config_from_file() to collect extensions.* in a string list while looking for core.repositoryformatversion. Then the function can iterate over the string list to call check_repo_format() itself.

Show 5 quoted lines
> I'm not sure if it's worth the trouble:
>
>   - ignoring extensions is likely to end up with broken results anyway
>     (e.g., ignoring a proposed objectformat extension means parsing any
>     object data is likely to encounter errors)

The primary reason why the safety calls for ignore/reject is the namespace collision. We may decide to use extensions.objectformat to record what hash algorithms are used for objects in the repository, while the end user and their tools may use it for totally different purpose (perhaps they have a custom script around "git repack" that reads the variable to learn what command line options e.g. --window=800 to pass). A new version of Git that supports SHA-2 will suddenly break their configuration, when the users are 100% happy with the current SHA-1 system, with the way their tool uses extensions.objectformat configuration variable and a newer version of Git that happens to know how to also work with SHA-2, using their v0 repository.

And the reasoning 'ignoring would make the problem get noticed anyway' does not apply to such users at all, does it?

We need to declare that any names under "extensions.*" is off limits by end users regardless and write it in big flasing red letters if we haven't already done so. It is enforced in v1 repositories by dying upon seeing an unrecognised extension, but not entirely. When the users are lucky, a known-but-name-collided extension may stop with a type error (e.g. "extensions.objectformat=frotz" may say "frotz is not among the accepted hash algorithms") but that is not guaranteed. In v0 repositories, enforcing it after the fact would cause the same trouble as the tightening caused.

Jeff King· Jul 16, 2020, 16:53 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On Thu, Jul 16, 2020 at 09:32:35AM -0700, Junio C Hamano wrote:
> We need to declare that any names under "extensions.*" is off limits
> by end users regardless and write it in big flasing red letters if
> we haven't already done so.

I thought this was already well-understood, and it was definitely part of the plan since 2015. Are other tools really sticking stuff in extensions.* that we don't know about?

-Peff
Junio C Hamano· Jul 16, 2020, 20:27 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> Hmm, this is actually a bit trickier than I expected because of the way
>> the code is written. It's much easier to complain about extensions in a
>> v0 repository than it is to ignore them. But I'm not sure if that isn't
>> the right way to go anyway.
>>
>> The patch I came up with is below (and goes on top of Jonathan's). Even
>> if we decide this is the right direction, it can definitely happen
>> post-v2.28.
>
> It must happen already in 'seen' if we want to keep bc/sha-2-part-3
> with us, though ;-)

FWIW, I needed to adjust t0001 while merging the SHA-2 topic. The internal use of "git config" via test_config triggers the "this is not a Git repository as the value of repositoryformatversion and the defined set of extensions are incompatible".

diff --cc t/t0001-init.sh index 6d2467995e,34d2064660..ff538c0eed

Show changes to t/t0001-init.sh +9 −0
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
 ...
 -test_expect_success 'extensions.objectFormat is not honored with repo version 0' '
++test_expect_success 'extensions.objectFormat would cause an error in repo version 0' '
+ 	git init --object-format=sha256 explicit-v0 &&
 -	test_config -C explicit-v0 core.repositoryformatversion 0 &&
 -	git -C explicit-v0 rev-parse --show-object-format >actual &&
 -	echo sha1 >expected &&
 -	test_cmp expected actual
++	v=$(git config --file=explicit-v0/.git/config core.repositoryformatversion 0) &&
++	test_when_finished "
++		git config --file=explicit-v0/.git/config core.repositoryformatversion $v
++	" &&
++	git config --file=explicit-v0/.git/config core.repositoryformatversion 0 &&
++	test_must_fail git -C explicit-v0 rev-parse --show-object-format >actual
+ '
Junio C Hamano· Jul 16, 2020, 16:49 UTC · re: Jeff King · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Jeff King <peff@peff.net> writes:
Show 14 quoted lines
> Subject: verify_repository_format(): complain about new extensions in v0 repo
>
> We made the mistake in the past of respecting extensions.* even when the
> repository format version was set to 0. This is bad because forgetting
> to bump the repository version means that older versions of Git (which
> do not know about our extensions) won't complain. I.e., it's not a
> problem in itself, but it means your repository is in a state which does
> not give you the protection you think you're getting from older
> versions.
>
> For compatibility reasons, we are stuck with that decision for existing
> extensions. However, we'd prefer not to extend the damage further. We
> can do that by catching any newly-added extensions and complaining about
> the repository format.
Looking good overall, but I needed this to build from the source.
Thanks.
 setup.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
Show changes to setup.c +8 −8
diff --git a/setup.c b/setup.c
index e29659b7b9..e69bd28ed6 100644
--- a/setup.c
+++ b/setup.c
@@ -457,10 +457,10 @@ enum extension_result {
  * Do not add new extensions to this function. It handles extensions which are
  * respected even in v0-format repositories for historical compatibility.
  */
-enum extension_result handle_extension_v0(const char *var,
-					  const char *value,
-					  const char *ext,
-					  struct repository_format *data)
+static enum extension_result handle_extension_v0(const char *var,
+						 const char *value,
+						 const char *ext,
+						 struct repository_format *data)
 {
 		if (!strcmp(ext, "noop")) {
 			return EXTENSION_OK;
@@ -483,10 +483,10 @@ enum extension_result handle_extension_v0(const char *var,
 /*
  * Record any new extensions in this function.
  */
-enum extension_result handle_extension(const char *var,
-				       const char *value,
-				       const char *ext,
-				       struct repository_format *data)
+static enum extension_result handle_extension(const char *var,
+					      const char *value,
+					      const char *ext,
+					      struct repository_format *data)
 {
 	if (!strcmp(ext, "noop-v1")) {
 		return EXTENSION_OK;
Jeff King· Jul 16, 2020, 16:56 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On Thu, Jul 16, 2020 at 09:49:14AM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > Subject: verify_repository_format(): complain about new extensions in v0 repo
> >
> > We made the mistake in the past of respecting extensions.* even when the
> > repository format version was set to 0. This is bad because forgetting
> > to bump the repository version means that older versions of Git (which
> > do not know about our extensions) won't complain. I.e., it's not a
> > problem in itself, but it means your repository is in a state which does
> > not give you the protection you think you're getting from older
> > versions.
> >
> > For compatibility reasons, we are stuck with that decision for existing
> > extensions. However, we'd prefer not to extend the damage further. We
> > can do that by catching any newly-added extensions and complaining about
> > the repository format.
> 
> Looking good overall, but I needed this to build from the source.

Oof, thanks. I did this as a one-off not even on a branch, and my config.mak magic loosens -Werror in that case (because usually a detached HEAD means I'm investigating some old commit, and quite a few of them don't build without warnings these days).

Thankfully it seems I only managed a minor error without the compiler there to help me. :)

-Peff
Junio C Hamano· Jul 16, 2020, 16:10 UTC · re: Jeff King · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Jeff King <peff@peff.net> writes:
> Yeah, I agree with this line of reasoning. I'd prefer to see it
> addressed now, so that we don't have to remember to do anything later.

Very true. Also the documentation may need some updating, e.g. "These 4 extensions are honored without adding repositoryFormatVersion to your repository (as special cases)" to avoid further confusion e.g. "why doesn't my objectFormat=SHA-3 does not take effect by itself?".

Show 6 quoted lines
> I.e., for this patch to put the existing known extensions into the
> "good" list for v0, locking it into place forever, and leaving the
> objectformat topic with nothing particular it needs to do.
>
> But in the name of -rc1 expediency, I'm also OK moving forward with this
> for now.
I'm OK, too, as I said.

I'd need to kick out bc/sha-2-part-3 topic out of my tree while that infrastructure is in place on top of these two patches, though.

Thanks.
Jonathan Nieder· Jul 16, 2020, 22:37 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

(replying from vacation; back tomorrow) Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
Show 8 quoted lines
>> Yeah, I agree with this line of reasoning. I'd prefer to see it
>> addressed now, so that we don't have to remember to do anything later.
>
> Very true.  Also the documentation may need some updating,
> e.g. "These 4 extensions are honored without adding
> repositoryFormatVersion to your repository (as special cases)" to
> avoid further confusion e.g. "why doesn't my objectFormat=SHA-3 does
> not take effect by itself?".
Yes, I agree, especially about documentation.
For 2.29, I would like to do or see the following:
- defining the list of repository format v0 supported extensions as
  "these and no more", futureproofing along the lines suggested in
  Peff's patch.  I like the general approach taken there since it
  allows parsing the relevant config in a single pass, so I think
  it basically takes the right approach.  (That said, it might be
  possible to simplify a bit with further changes, e.g. by using the
  configset API.)
  When doing this for real, we'd want to document the set of
  supported extensions.  That is especially useful to independent
  implementers wanting to support Git's formats, since it tells
  them "this is the minimum set of extensions that you must
  either handle or error out cleanly on to maintain compatibility
  with Git's repository format v0".
 
- improving the behavior when an extension not supported in v0 is
  encountered in a v0 repository.  For extensions that are supported
  in v1 and not v0, we should presumably error out so the user can
  repair the repository, and we can put the "noop" extension in that
  category for the sake of easy testing.  We can also include a check
  in "git fsck" for repositories that request the undefined behavior
  of v0 repositories with non-v0 extensions, for faster diagnosis.
  What about unrecognized extensions that are potentially extensions
  yet to be defined?  Should these be silently ignored to match the
  historical behavior, or should we error out even in repository
  format v0?  I lean toward the latter; we'll need to be cautious,
  though, e.g. by making this a separate patch so we can easily tweak
  it if this ends up being disruptive in some unanticipated way.
- making "git init" use repository format v1 by default.  It's been
  long enough that users can count on Git implementations supporting
  it.  This way, users are less likely to run into v0+extensions
  confusion, just because users are less likely to be using v0.

Does that sound like a good plan to others? If so, are there any steps beyond the two first patches in jn/v0-with-extensions-fix that we would want in order to prepare for it in 2.28?

My preference would be to move forward in 2.28 with the first two patches in that topic branch (i.e., *not* the third yet), since they don't produce any user facing behavior that would create danger for users or clash with this plan. Today, the only extensions we recognize are in that set of extensions that we'll want to continue to recognize in v0 (except possibly the for-testing extension "noop"). The steps to take with additional extensions are more subtle so it seems reasonable for them to bake in "next" and then "master" for a 2.29 release.

Thanks, Jonathan

Junio C Hamano· Jul 16, 2020, 23:50 UTC · re: Jonathan Nieder · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 14 quoted lines
> - defining the list of repository format v0 supported extensions as
>   "these and no more", futureproofing along the lines suggested in
>   Peff's patch.  I like the general approach taken there since it
>   allows parsing the relevant config in a single pass, so I think
>   it basically takes the right approach.  (That said, it might be
>   possible to simplify a bit with further changes, e.g. by using the
>   configset API.)
>
>   When doing this for real, we'd want to document the set of
>   supported extensions.  That is especially useful to independent
>   implementers wanting to support Git's formats, since it tells
>   them "this is the minimum set of extensions that you must
>   either handle or error out cleanly on to maintain compatibility
>   with Git's repository format v0".
Good.
Show 14 quoted lines
> - improving the behavior when an extension not supported in v0 is
>   encountered in a v0 repository.  For extensions that are supported
>   in v1 and not v0, we should presumably error out so the user can
>   repair the repository, and we can put the "noop" extension in that
>   category for the sake of easy testing.  We can also include a check
>   in "git fsck" for repositories that request the undefined behavior
>   of v0 repositories with non-v0 extensions, for faster diagnosis.
>
>   What about unrecognized extensions that are potentially extensions
>   yet to be defined?  Should these be silently ignored to match the
>   historical behavior, or should we error out even in repository
>   format v0?  I lean toward the latter; we'll need to be cautious,
>   though, e.g. by making this a separate patch so we can easily tweak
>   it if this ends up being disruptive in some unanticipated way.

I disagree with your first paragraph. Those that weren't honored by mistake back in v0 days, in addition to those that aren't known to us even now, should just be silently ignored, not causing an error.

> - making "git init" use repository format v1 by default.  It's been
>   long enough that users can count on Git implementations supporting
>   it.  This way, users are less likely to run into v0+extensions
>   confusion, just because users are less likely to be using v0.
Absolutely.  I would think this is a very good move.
Show 8 quoted lines
> Does that sound like a good plan to others?  If so, are there any
> steps beyond the two first patches in jn/v0-with-extensions-fix that
> we would want in order to prepare for it in 2.28?
>
> My preference would be to move forward in 2.28 with the first two
> patches in that topic branch (i.e., *not* the third yet), since they
> don't produce any user facing behavior that would create danger for
> users or clash with this plan.

Yup, I agree. I'd give another name to the third commit and then rewind jn/v0-with-extensions-fix by one to prevent mistakes from happening. Thanks.

Jeff King· Jul 17, 2020, 15:27 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On Thu, Jul 16, 2020 at 04:50:34PM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> > - improving the behavior when an extension not supported in v0 is
> >   encountered in a v0 repository.  For extensions that are supported
> >   in v1 and not v0, we should presumably error out so the user can
> >   repair the repository, and we can put the "noop" extension in that
> >   category for the sake of easy testing.  We can also include a check
> >   in "git fsck" for repositories that request the undefined behavior
> >   of v0 repositories with non-v0 extensions, for faster diagnosis.
> >
> >   What about unrecognized extensions that are potentially extensions
> >   yet to be defined?  Should these be silently ignored to match the
> >   historical behavior, or should we error out even in repository
> >   format v0?  I lean toward the latter; we'll need to be cautious,
> >   though, e.g. by making this a separate patch so we can easily tweak
> >   it if this ends up being disruptive in some unanticipated way.
> 
> I disagree with your first paragraph.  Those that weren't honored by
> mistake back in v0 days, in addition to those that aren't known to us
> even now, should just be silently ignored, not causing an error.

That's very much the opposite of my patch. As we add new extensions, those "unknowns" will start to die().

I remain unconvinced that there are a bunch of unknown extension.* config options hanging around in the wild, but maybe I'm being naive. It seems to me more likely that users will be helped by warning about extensions that _should_ have had v1 set than that they will be harmed because they put random crap in their extensions.* config. But maybe you know of a specific example?

Anyway, if we move to "v1" as the default for "git init" anyway, then the number of people being helped would become much smaller.

Show 8 quoted lines
> > My preference would be to move forward in 2.28 with the first two
> > patches in that topic branch (i.e., *not* the third yet), since they
> > don't produce any user facing behavior that would create danger for
> > users or clash with this plan.
> 
> Yup, I agree.  I'd give another name to the third commit and then
> rewind jn/v0-with-extensions-fix by one to prevent mistakes from
> happening.  Thanks.

OK. I was confused to see it still at the tip in the latest What's Cooking, but I think we're just crossing emails. :)

-Peff
Junio C Hamano· Jul 17, 2020, 17:07 UTC · re: Jeff King · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

Jeff King <peff@peff.net> writes:
> Anyway, if we move to "v1" as the default for "git init" anyway, then
> the number of people being helped would become much smaller.
Yup. So in that sense I do not think I care too deeply either way.
Show 11 quoted lines
>> > My preference would be to move forward in 2.28 with the first two
>> > patches in that topic branch (i.e., *not* the third yet), since they
>> > don't produce any user facing behavior that would create danger for
>> > users or clash with this plan.
>> 
>> Yup, I agree.  I'd give another name to the third commit and then
>> rewind jn/v0-with-extensions-fix by one to prevent mistakes from
>> happening.  Thanks.
>
> OK. I was confused to see it still at the tip in the latest What's
> Cooking, but I think we're just crossing emails. :)
Yes.
Jeff King· Jul 17, 2020, 15:22 UTC · re: Jonathan Nieder · lore

Re: [PATCH 2/2] repository: allow repository format upgrade with extensions

On Thu, Jul 16, 2020 at 03:37:19PM -0700, Jonathan Nieder wrote:
Show 16 quoted lines
> For 2.29, I would like to do or see the following:
> 
> - defining the list of repository format v0 supported extensions as
>   "these and no more", futureproofing along the lines suggested in
>   Peff's patch.  I like the general approach taken there since it
>   allows parsing the relevant config in a single pass, so I think
>   it basically takes the right approach.  (That said, it might be
>   possible to simplify a bit with further changes, e.g. by using the
>   configset API.)
> 
>   When doing this for real, we'd want to document the set of
>   supported extensions.  That is especially useful to independent
>   implementers wanting to support Git's formats, since it tells
>   them "this is the minimum set of extensions that you must
>   either handle or error out cleanly on to maintain compatibility
>   with Git's repository format v0".

I think we should still consider people setting v0 along with extensions to be a bug. It was never documented to work that way and we are being nice by keeping the existing behavior, but it is still wrong (and pre-extension versions of Git will silently ignore them). I don't mind making other implementers aware of the special status, but we should be careful not to endorse the broken setup.

> - making "git init" use repository format v1 by default.  It's been
>   long enough that users can count on Git implementations supporting
>   it.  This way, users are less likely to run into v0+extensions
>   confusion, just because users are less likely to be using v0.

That's probably reasonable. It will be mildly annoying for people like me who are often testing old versions of Git, but I'm sure I will survive.

We should make sure that all major implementations handle v1 reasonably first, though (and that they did so long enough ago that it's not likely to cause problems).

Show 9 quoted lines
> My preference would be to move forward in 2.28 with the first two
> patches in that topic branch (i.e., *not* the third yet), since they
> don't produce any user facing behavior that would create danger for
> users or clash with this plan.  Today, the only extensions we
> recognize are in that set of extensions that we'll want to continue to
> recognize in v0 (except possibly the for-testing extension "noop").
> The steps to take with additional extensions are more subtle so it
> seems reasonable for them to bake in "next" and then "master" for a
> 2.29 release.

I'm OK with the plan to ship the first two patches for 2.28, and leave my patch for later (or even soften it from "die" to "ignore with a warning").

I think leaving "noop" in that set of special extensions makes sense, since it lets us test that case easily (and I added a "noop-v1" in my patch to test the other one; clearly we could also flip it and have noop-v0).

-Peff
Johannes Schindelin· Jul 16, 2020, 08:13 UTC · re: Jonathan Nieder · lore

Re: [PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions)

Hi Jonathan,
On Wed, 15 Jul 2020, Jonathan Nieder wrote:
Show 9 quoted lines
> Junio C Hamano wrote:
>
> > Here is my quick attempt to see how far we can go with the
> > "different endgame" approach, to be applied on top of those two
> > patches.
>
> Here are patches implementing the minimal fix that I'd recommend.
> These apply against "master" without requiring any other patches
> as prerequisites.  Thoughts?

IIUC all of the existing `extensions.*` predate the reverted strict check, right? And the idea is that future `extensions.*` will only work when `repositoryFormatVersion` is larger than 1, right?

I would have been fine with Junio's patch on top of Stolee's, and I am equally fine with this patch series. My main aim is not so much future-proofing, though, as it is to avoid regressions in existing setups.

Thanks, Dscho

Derrick Stolee· Jul 16, 2020, 12:17 UTC · re: Johannes Schindelin · lore

Re: [PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions)

On 7/16/2020 4:13 AM, Johannes Schindelin wrote:
Show 21 quoted lines
> Hi Jonathan,
> 
> On Wed, 15 Jul 2020, Jonathan Nieder wrote:
> 
>> Junio C Hamano wrote:
>>
>>> Here is my quick attempt to see how far we can go with the
>>> "different endgame" approach, to be applied on top of those two
>>> patches.
>>
>> Here are patches implementing the minimal fix that I'd recommend.
>> These apply against "master" without requiring any other patches
>> as prerequisites.  Thoughts?
> 
> IIUC all of the existing `extensions.*` predate the reverted strict check,
> right? And the idea is that future `extensions.*` will only work when
> `repositoryFormatVersion` is larger than 1, right?
> 
> I would have been fine with Junio's patch on top of Stolee's, and I am
> equally fine with this patch series. My main aim is not so much
> future-proofing, though, as it is to avoid regressions in existing setups.

I'm fine either way. I think that Jonathan's patch comes from a more informed place than my patches, so his are probably safer.

The situation that caught my interest is covered by this test that was part of my patches:

Show changes to t/t1091-sparse-checkout-builtin.sh +12 −1
diff --git a/t/t1091-sparse-checkout-builtin.sh b/t/t1091-sparse-checkout-builtin.sh
index 7cd45fc1394..6c0b82c3930 100755
--- a/t/t1091-sparse-checkout-builtin.sh
+++ b/t/t1091-sparse-checkout-builtin.sh
@@ -68,6 +68,18 @@ test_expect_success 'git sparse-checkout init' '
        check_files repo a
 '
 
+test_expect_success 'git sparse-checkout works if repository format is wrong' '
+       test_when_finished git -C repo config core.repositoryFormatVersion 1 &&
+       git -C repo config --unset core.repositoryFormatVersion &&
+       git -C repo sparse-checkout init &&
+       git -C repo config core.repositoryFormatVersion >actual &&
+       echo 1 >expect &&
+       git -C repo config core.repositoryFormatVersion 0 &&
+       git -C repo sparse-checkout init &&
+       git -C repo config core.repositoryFormatVersion >actual &&
+       test_cmp expect actual
+'
+
 test_expect_success 'git sparse-checkout list after init' '
        git -C repo sparse-checkout list >actual &&
        cat >expect <<-\EOF &&

and this test passes with Jonathan's series. I think this kind
of behavior is covered by his change to the 'converting to partial
clone fails with noop extension' test in t0410-partial-clone.sh,
so a duplicate test in t1091-sparse-checkout-builtin.sh may be
overkill.

Thanks, all.

-Stolee

← back to recent threads