From: "brian m. carlson" <firstname.lastname@example.org>
To: Junio C Hamano <email@example.com>
Cc: "Martin Ågren" <firstname.lastname@example.org>,
"Git Mailing List" <email@example.com>
Subject: Re: [PATCH] Documentation: mark `--object-format=sha256` as experimental
Date: Fri, 14 Aug 2020 00:51:51 +0000 [thread overview]
Message-ID: <20200814005151.GI8085@camp.crustytoothpaste.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On 2020-08-13 at 20:34:10, Junio C Hamano wrote:
> Martin Ågren <firstname.lastname@example.org> writes:
> >> IOW, you question "if we go a few releases without any major issues"
> >> part? I tend to agree that for a large change like this, a few
> >> releases may not be sufficiently long time for a feature that is
> >> marked as experimental in big flashing red letters to get exercised
> >> enough to get major issues noticed.
> > Yeah, thanks for summarizing what I failed to express using so many
> > words.
> > I'm fully open to the idea that some people want to leave SHA-1 behind
> > and that they can do it today, in some "local" sense. If those people
> > are fully aware that they are guinea pigs, it might actually be ok for
> > us to subject them to a few rounds of "oops, Git v2.32.0 produces data
> > that v2.34.0 and later will barf on". Or at least it would be on our
> > table whether we wanted to be that cavalier.
> > Once SHA-256 repos as such are no longer experimental, I fear that we
> > can only buy ourselves that leeway by introducing fiftyeleven different
> > config flags for "please produce auxiliary files X even if you don't
> > actually use them", "please do use X, and I'm fully expecting to trip on
> > them if you decide to tweak them in backwards-incompatible ways", and so
> > on. The alternative to buying such leeway might be to establish, pretty
> > early on, a respectable set of things we support "for compatibility
> > reasons".
> OK, so can we resolve this one way or the other and move on?
> For now, I'd vote for applying this warning patch, but with or
> without such warning, it is more important to iron out those details
> we fear might have to change.
I'm fine with applying this patch.
As for changes, I don't think there's any changes we need to make for a
stage 4 implementation. It works and it passes the testsuite. I've
verified the block and gcrypt SHA-256 implementations produce identical
results, which was my major worry. Other than the philosophical
disagreement over whether index v1 and v2 should support SHA-256, I
don't think there's any points of contention.
When we add support for SHA-1 interoperability, then we'll need pack
index v3, proper multi-pack index support, and the loose object index.
Those are being written at the moment, and I think it's fine to add a
tool to generate the necessary files once that code is in place (which,
it's looking like, can just be a shell script that pipes every loose
object to git hash-object and rebuilds the pack indexes). Support for
interoperability is an additional extension, so we don't have any
compatibility concerns and we can generate all of those files based on
I don't plan to enable support for extensions.compatObjectFormat without
all of the required pieces in place. There won't be any incremental
brian m. carlson: Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2020-08-14 0:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 20:23 [PATCH] Documentation: mark `--object-format=sha256` as experimental Martin Ågren
2020-08-06 23:08 ` brian m. carlson
2020-08-07 14:08 ` Martin Ågren
2020-08-07 20:50 ` Junio C Hamano
2020-08-07 22:15 ` Martin Ågren
2020-08-13 20:34 ` Junio C Hamano
2020-08-14 0:51 ` brian m. carlson [this message]
2020-08-16 10:01 ` [PATCH v2] " Martin Ågren
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:
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 \
* 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
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).