From: Eric Wong <e@80x24.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
git@vger.kernel.org, Jeff King <peff@peff.net>,
Taylor Blau <me@ttaylorr.com>, Derrick Stolee <stolee@gmail.com>,
Patrick Steinhardt <ps@pks.im>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Efficiently storing SHA-1 ↔ SHA-256 mappings in compatibility mode
Date: Fri, 29 Aug 2025 19:51:09 +0000 [thread overview]
Message-ID: <20250829195109.M344703@dcvr> (raw)
In-Reply-To: <aLDNj5GPYA9nR3xR@fruit.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> wrote:
> SQLite is not an option because it performs poorly with Java and we want
> our formats to work with other implementations, like JGit. That's why
> we created reftable instead of using SQLite.
Interesting. I would've thought it'd be a solved problem by now
given the popularity of both SQLite and Java. I actually
expected choosing a more common/standard file format would make
life easier for hackers of alternative git implementations.
Searching for `pure java sqlite' reveals some projects, but
I'm not a Java user at all so can't comment on the quality of
implementations:
https://html.duckduckgo.com/html/?q=pure+java+sqlite
Fwiw, the US Library of Congress has SQLite as a recommended
data format for several years, now:
https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml
Nowadays I'm more concerned about the continued relevance or
even existence of the LoC than SQLite.
> Also, in general, I'm not interested in being tied to a single
> implementation. If the developers of SQLite decide to dramatically
> change the license of all their code like Oracle did with Berkeley DB,
> we're going to have a problem. Yes, we can use the older versions, but
> we'd still need people to maintain the library and update it.
Whereas we'd be implementing and maintaining yet another one-off
data format from day one instead of waiting for an eventuality
which may never come. SQLite 3 has far surpassed the stability
and use of Berkeley DB; there's not a lot of similar formats
that might replace it (e.g. GDBM, LMDB). So I'd expect there'd
be no shortage of hackers able to maintain a usable fork if push
comes to shove.
Fwiw, I consider the proliferation of data formats and protocols
the biggest threat to digital freedom and security. Even when
the implementations are open source it feels like a huge drain
to have to constantly deal reviewing/porting code to deal with
more formats.
prev parent reply other threads:[~2025-08-29 19:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 1:09 Efficiently storing SHA-1 ↔ SHA-256 mappings in compatibility mode brian m. carlson
2025-08-14 14:22 ` Junio C Hamano
2025-08-14 22:06 ` brian m. carlson
2025-08-14 22:51 ` Junio C Hamano
2025-08-15 15:27 ` Derrick Stolee
2025-09-03 6:43 ` Patrick Steinhardt
2025-08-27 19:08 ` Eric Wong
2025-08-28 14:53 ` Junio C Hamano
2025-08-28 21:43 ` brian m. carlson
2025-08-29 19:51 ` Eric Wong [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250829195109.M344703@dcvr \
--to=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
--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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.