On Wed, Nov 24, 2021 at 7:53 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > > >> ... Doesn't the ref backend already ensure that > >> the message is not an incomplete line? If you feed a single > >> complete line when updating, I do not think the backend should add > >> any extra LF relative to the given message: > > > > But it does, currently. As of > > > > commit 523fa69c36744ae6779e38614cb9bfb2be552923 > > Author: Junio C Hamano <gitster@xxxxxxxxx> > > .. > > - We expect that a reflog message consists of a single line. The > > file format used by the files backend may add a LF after the > > > > it is the job of the files ref backend to add a LF, and the input to > > the ref backend is a string without trailing LF. But the files backend > > then produces that message with a LF, when reading back the data, eg. > > Ah, perhaps our confusion comes from the fact that I view the ref > API as a whole and do not draw a fine line of distinction between > the "ref API implementation common across backends" vs "what ref > files backend does". But as the implementor of one backend, you > obviously have to care. Having the read function return something different than what the write gets still seems odd to me. How about having copy_reflog_msg() trim trailing space and then always add LF? The files backend can assert that the string ends in LF, and doesn't need to add LF itself. -- 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
