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

Jonathan Nieder [off-list ref] writes:

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

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

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.

On Thu, Jul 16, 2020 at 04:50:34PM -0700, Junio C Hamano wrote:

quoted

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

quoted

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