On Thu, Jul 16, 2020 at 03:37:19PM -0700, Jonathan Nieder wrote: > 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). > 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
