Re: [PATCH v4 00/28] Support reftable ref backend for Git

From: Han-Wen Nienhuys <hanwen@google.com>
Date: Aug 26, 2021, 08:56 UTC
Message-ID: <CAFQ2z_NBmKrVMeuTb=qeG_VSBWC7287-gGB9GhpokLZrmNiC0A@mail.gmail.com>
In-Reply-To: <xmqqfsuwha5p.fsf@gitster.g>

On Thu, Aug 26, 2021 at 10:39 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> > For Han-Wen's v3 of this see:
> > https://lore.kernel.org/git/pull.1054.v3.git.git.1629207607.gitgitgadget@gmail.com/
> >
> > I've got no desire to take over the reftable topic in its entirety,
> > but think given the rationale in
> > https://lore.kernel.org/git/877dgch4rn.fsf@evledraar.gmail.com/
> > (summarized in
> > https://lore.kernel.org/git/87y28sfokk.fsf@evledraar.gmail.com/) that
> > having the refs API fixes I noted above wait on the still-unstable
> > reftable doesn't make sense.
>
> Of course, you and Han-Wen are in much better position to judge the
> relative merit to decide which one should go first than I am, but I
> had an impression that the errno thing was even less stable, with
> API churn that deliberately broke the other topic in flight, which
> appeared to be just irresponsible.

The bottom part of the errno series that I contributed has had ample scrutiny. It's a cleanup, and all-in-all much less experimental than the reftable work. However, because it changes a calling convention in the ref backend API, it causes difficulty with other topics (notably: reftable). I would be in favor of graduating the series upto "refs: make errno output explicit for read_raw_ref_fn" early to provide a stable basis for other patches.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado