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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 16, 2020, 16:32 UTC
Message-ID: <xmqq5zanifoc.fsf@gitster.c.googlers.com>
In-Reply-To: <20200716122513.GA1050962@coredump.intra.peff.net>

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.