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

[Junio C Hamano <gitster@pobox.com>]

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 ;-)

> 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.

> 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.