On Thu, Aug 26, 2021 at 10:39 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > For Han-Wen's v3 of this see: > > https://lore.kernel.org/git/pull.1054.v3.git.git.1629207607.gitgitgadget@xxxxxxxxx/ > > > > 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@xxxxxxxxxxxxxxxxxxx/ > > (summarized in > > https://lore.kernel.org/git/87y28sfokk.fsf@xxxxxxxxxxxxxxxxxxx/) 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
