On Mon, Nov 29, 2021 at 11:14 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > This helps for reftable support, and will help if we want to reconsider > > under which conditions reflogs get created/updated. > > Having looked at this in a bit more detail than last time > (https://lore.kernel.org/git/211123.864k83w3y4.gmgdl@xxxxxxxxxxxxxxxxxxx/) > I applaud the goals, but to be blunt the specific approach just seems a > bit backwards to me. > > As noted in that message I have patches to tweak the "verbose" mode to > be backend-independent, which as we see from your series is one thing in > the files backend that consumes the "message" and assumes things about > newlines. In v2, I went with Jun's suggestion, and left the newlines alone, just trimming them in refs/debug.c . I think that makes most of your mail irrelevant? > Perhaps reftable is capable of just handing the underlying code pointers > into the mmap()'d file, so we could even skip all (re)allocations? Or if > not, that certainly seems like a sensible thing to anticipate in a > backend-independent interface. We could do that in the file backend if > we were a bit smarter and used mmap() instead of the > fopen()/read-in-a-loop pattern. It sounds like premature optimization. Reading reflogs is not usually a performance sensitive operation. Also, if you hand out mmap'd pointers, how would the reftable storage code know when it is safe to close and munmap the file? > > Just my 0.02, if you're interested in running with the below assume my > SOB. What is SOB in this context? -- 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
