Re: [PATCH] setup: tweak upgrade policy to grandfather worktreeconfig

Hi,

Derrick Stolee wrote:

On 7/13/2020 4:18 PM, Junio C Hamano wrote:

quoted

The "fail and warn" approach introduced in the previous step may be
with smaller impact to the codebase, but

 - it requires the end-user to read, understand and execute the
   manual upgrade

 - it encourages to follow the same procedure blindly, making the
   protection even less useful

Let's instead keep failing hard without teaching how to bypass the
repository protection, but allow upgrading even when only the
worktreeconfig extension exists in an old repository, which is
likely to be set by a broke version of Git that did not update the
repository version when setting the extension.

This is a more subtle way to handle the case. In fact, it
silently makes extensions.worktreeConfig work as it did in 2.27,
which means users will not have any troubles after upgrading.

I'd like to propose a different endgame:

Instead of looking at `extensions.*` settings one by one to see how
various implementations handled them with repositoryFormatVersion=0,
what if we treat repositoryFormatVersion=0 as a synonym of version=1?

That is:

1. in new repositories, set repositoryFormatVersion = 1, since (1) Git
   versions in the wild should all already know how to handle it and
   (2) as we've learned, other Git implementations need to understand
   some of extensions.* anyway

2. whenever setting any extensions.*, automatically upgrade to
   repositoryFormatVersion = 1

3. when in an existing repository with extensions.* set and
   repositoryFormatVersion = 0, act as though repositoryFormatVersion = 1

4. document this new behavior with repositoryFormatVersion = 0 in
   Documentation/technical/repository-version.txt

This way, the result is simpler than where we started.

Unfortunately, we are not even that consistent about what to do with
extensions.* settings when repositoryFormatVersion = 0 today.  So
we'll have to exercise some care and analyze them one by one to make
sure this is safe (and if it isn't, at *that* point we'd come up with
a more complex variant on (2) and (3) above).

It's too late to go that far for 2.28.  It would be tempting to try a
simple revert of 14c7fa269e4 (check_repository_format_gently(): refuse
extensions for old repositories, 2020-06-05) to get back to tried and
true behavior but that does not do enough --- it still produces an
error when trying to upgrade repository format when any extensions are
set.  So how about such a revert plus Junio's patch plus the analogous
change to Junio's patch for

  extensions.preciousObjects
  extensions.partialClone

?

Thanks,
Jonathan