Re: [PATCH 2/4] refs: trim newline from reflog message
- From
Han-Wen Nienhuys <hanwen@google.com>
- Date
- Nov 24, 2021, 19:06 UTC
- Message-ID
- <CAFQ2z_PqgwYy+RxQm7d7WDQYvQQ2vVE0cXHdDKNwQJm3Xc+NFw@mail.gmail.com>
- In-Reply-To
- <xmqqpmqp2xmz.fsf@gitster.g>
On Wed, Nov 24, 2021 at 7:53 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 25 quoted lines
> > Han-Wen Nienhuys <hanwen@google.com> 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@pobox.com> > > .. > > - 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