From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Derrick Stolee <stolee@gmail.com>,
Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, delphij@google.com,
Huan Huan Chen <huanhuanchen@google.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH 2/2] repository: allow repository format upgrade with extensions
Date: Thu, 16 Jul 2020 15:37:19 -0700 [thread overview]
Message-ID: <20200716223719.GA899@gmail.com> (raw)
In-Reply-To: <xmqqd04vigpy.fsf@gitster.c.googlers.com>
(replying from vacation; back tomorrow)
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>> Yeah, I agree with this line of reasoning. I'd prefer to see it
>> addressed now, so that we don't have to remember to do anything later.
>
> Very true. Also the documentation may need some updating,
> e.g. "These 4 extensions are honored without adding
> repositoryFormatVersion to your repository (as special cases)" to
> avoid further confusion e.g. "why doesn't my objectFormat=SHA-3 does
> not take effect by itself?".
Yes, I agree, especially about documentation.
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".
- 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.
- 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.
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. 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.
Thanks,
Jonathan
next prev parent reply other threads:[~2020-07-16 23:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 21:55 [PATCH] setup: warn about un-enabled extensions Johannes Schindelin via GitGitGadget
2020-07-13 22:48 ` Junio C Hamano
2020-07-14 0:24 ` Derrick Stolee
2020-07-14 12:21 ` Johannes Schindelin
2020-07-14 15:27 ` Junio C Hamano
2020-07-14 15:40 ` Derrick Stolee
2020-07-14 20:30 ` Johannes Schindelin
2020-07-14 20:47 ` Junio C Hamano
2020-07-15 16:09 ` Junio C Hamano
2020-07-15 17:01 ` Junio C Hamano
2020-07-15 18:00 ` Derrick Stolee
2020-07-15 18:09 ` Junio C Hamano
2020-07-15 18:40 ` Derrick Stolee
2020-07-15 19:16 ` Johannes Schindelin
2020-07-15 18:15 ` Junio C Hamano
2020-07-15 19:21 ` Johannes Schindelin
2020-07-15 18:20 ` Jonathan Nieder
2020-07-16 2:06 ` Junio C Hamano
2020-07-16 6:20 ` [PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions) Jonathan Nieder
2020-07-16 6:24 ` [PATCH 1/2] Revert "check_repository_format_gently(): refuse extensions for old repositories" Jonathan Nieder
2020-07-16 10:56 ` Jeff King
2020-07-16 6:28 ` [PATCH 2/2] repository: allow repository format upgrade with extensions Jonathan Nieder
2020-07-16 7:01 ` Junio C Hamano
2020-07-16 11:00 ` Jeff King
2020-07-16 12:25 ` Jeff King
2020-07-16 12:53 ` Derrick Stolee
2020-07-16 16:32 ` Junio C Hamano
2020-07-16 16:53 ` Jeff King
2020-07-16 20:27 ` Junio C Hamano
2020-07-16 16:49 ` Junio C Hamano
2020-07-16 16:56 ` Jeff King
2020-07-16 16:10 ` Junio C Hamano
2020-07-16 22:37 ` Jonathan Nieder [this message]
2020-07-16 23:50 ` Junio C Hamano
2020-07-17 15:27 ` Jeff King
2020-07-17 17:07 ` Junio C Hamano
2020-07-17 15:22 ` Jeff King
2020-07-16 8:13 ` [PATCH 0/2] extensions.* fixes for 2.28 (Re: [PATCH] setup: warn about un-enabled extensions) Johannes Schindelin
2020-07-16 12:17 ` Derrick Stolee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200716223719.GA899@gmail.com \
--to=jrnieder@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=delphij@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=huanhuanchen@google.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).