On Fri, Apr 30, 2021 at 8:02 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > I like the general direction to move away from errno, which may make > > sense only in the context of files backend (e.g. ENOENT would be > > left in errno, only because the original "loose ref" implementation > > used one file per ref, when a ref we wanted to see did not exist) > > and having other backends use the same errno would not make much > > sense, as it is not the goal to make other backends like reftable > > emulate files backend. > > > > I wonder if in the ideal world, we'd rather want to define our own > > enum, not <errno.h>, that is specific to failure modes of ref API > > functions and signal failures by returning these values (and the > > enum includes 0 as a value to signal success, all other errors are > > negative values). I think it would be healthy to have a set of canonical error codes in general, but I don't know if this will help here. The files and packed backend want to communicate about very specific conditions (ENOENT, EISDIR, ENOTDIR), which seem too low-level to put in a generic error code. > In any case, the change in the function signature helped me catch > that this series invalidates what has been queued on hn/reftable > without updating that topic to align with the new way to handle the > errno (it would have become a silent semantic failure if we instead > encoded the "failure" in the return value). > > The following is what I am tentatively using for tonight's > integration when merging this and hn/reftable together to the 'seen' > branch. That sounds right. How should I post the next update to hn/reftable ? (based on which branch?) -- 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
