On Mon, Nov 29, 2021 at 11:14 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
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@evledraar.gmail.com/ (local))
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