Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > On Mon, Nov 29, 2021 at 8:20 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: >> >> > On Fri, Nov 26, 2021 at 9:16 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> >> >> The API promises to have only LF, not CRLF, at the end, so >> >> strbuf_trim_trailing_newline() is a bit overkill (and if payload >> >> happened to end with CR, we would lose it). >> > >> > it would be best if there was a way to escape characters (ie. "\n" => >> > "\\n"). Do we have a function for that? >> >> Mere escaping would not work in a backward compatible way, without a >> trick. It was envisioned that we probably could encode *and* signal > > I'm talking about the debug output, which isn't subject to > compatibility guarantees. There is no need to show "\n" in the debug output in the first place, no? The message part stored in the reflog database is already normalized to have each runs of whitespaces (including CR and LF) turned and squashed into a single SP, so the LF at the end is constant that the debug output can unconditionally strip without losing information. Or are we talking about logging the _input_ to be recorded as the message for a new reflog entry? Then I agree we can do whatever, and if you prefer C-style quoting, the helpers in quote.c are your friends. Thanks.
