Message ID | cover-v4-00.28-00000000000-20210823T120208Z-avarab@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Support reftable ref backend for Git | expand |
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > This is a version of the reftable series queued on top of my > just-re-rolled fixes to the refs APIs, which it can make use of. For > the base topics see: > > https://lore.kernel.org/git/cover-v5-00.13-00000000000-20210823T113115Z-avarab@gmail.com/ > https://lore.kernel.org/git/cover-v10-0.8-00000000000-20210823T114712Z-avarab@gmail.com/ > > 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. > I'll let Han-Wen deal with that squashing in a presumed future v5 of > this, assuming of course that Junio's happy with the plan of basing > hn/reftable on the refs API fixes above. > > I'm not sure that the fix I have in 27/28 is the right one, perhaps > we've already got information about what the tip OID of the refname is > at that point in git_reftable_reflog_expire() via some API I missed, > but that fix works, and is clearly more correct than the outstanding > segfault.
On Thu, Aug 26, 2021 at 10:39 AM Junio C Hamano <gitster@pobox.com> wrote: > > 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 <hanwen@google.com> writes: > 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. Very glad to see that the two of you are in agreement of the order and the approach. Let me replace the topics that have been queued on 'seen' with the latest ones from Ævar, and we can go from there. Thanks for a quick response.