git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Han-Wen Nienhuys <hanwenn@gmail.com>
Cc: git <git@vger.kernel.org>, Josh Steadmon <steadmon@google.com>
Subject: Re: reftable & jgit compatibility
Date: Thu, 4 Apr 2024 09:20:07 +0200	[thread overview]
Message-ID: <Zg5Up_kSvOmQODO3@tanuki> (raw)
In-Reply-To: <CAOw_e7Zzc2uLX0FtkJ3fB+wuNJt5piMmoYVes+ayApe8BEN3+g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

On Thu, Apr 04, 2024 at 08:44:44AM +0200, Han-Wen Nienhuys wrote:
> On Thu, Apr 4, 2024 at 8:23 AM Patrick Steinhardt <ps@pks.im> wrote:
> 
> > > I think the easiest way to make this happen is if CGit would ship a
> > > command to dump a raw reftable in a release soonish. Then JGit could
> > > use that command to cross-check that a JGit-written reftable can be
> > > read correctly by the CGit code.  By shipping just the dumper you
> > > avoid having to wait for proper reftable support to land in git.
> >
> > You do realize that "proper reftable support" has already landed, right?
> 
> I had not realized this, and that's great news!
> 
> > So you can just use Git to create a reftable-enabled repository, write
> > commits and then use JGit to access the whole repository instead of only
> > checking a single table.
> 
> For testing, it's probably easier if you can work in terms of
> individual tables (because that is where the complexity lies:
> different blocksizes, restart frequencies, with index, without index,
> with reflog, without reflog etc.), but one can create controlled
> individual tables by creating a whole repo and then compacting it.
> OTOH, this would necessitate exposing all writer options to the git
> CLI, which is maybe a bit much.

Potentially, yeah. But as you say, it's likely quite some complexity to
expose this via the CLI directly. So for now, I'm going to focus on some
basic interoperability tests in Git that act on the repository level. We
can build on that and expand them as required when the need arises.

Different blocksizes is definitely a bit of a sore spot right now. I do
plan to expose write options via Git config options in the future, e.g.
something like "reftable.blockSize" or "reftable.restartCount". But for
all I know the CGit reftable library doesn't yet play nice with block
sizes other than 4k.

I didn't yet want to introduce configs which are specific to reftables
in the first release of Git with the reftable backend, so I pushed this
issue further down. I do plan to work on that in the next release cycle
though.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-04-04  7:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 10:36 reftable & jgit compatibility Han-Wen Nienhuys
2024-04-03 10:47 ` Patrick Steinhardt
2024-04-03 15:57   ` Han-Wen Nienhuys
2024-04-04  6:23     ` Patrick Steinhardt
2024-04-04  6:44       ` Han-Wen Nienhuys
2024-04-04  7:20         ` Patrick Steinhardt [this message]
2024-04-04  8:36           ` Han-Wen Nienhuys
2024-04-03 20:54   ` Jeff King
2024-04-04  6:29     ` Patrick Steinhardt
2024-04-03 15:51 ` Luca Milanesio
2024-04-03 16:42   ` Junio C Hamano

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=Zg5Up_kSvOmQODO3@tanuki \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=hanwenn@gmail.com \
    --cc=steadmon@google.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).