On Wed, Nov 24, 2021 at 8:27 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > > > $ GIT_TRACE_REFS="1" git branch -m bla blub > > .. > > 12:03:59.408705 refs/debug.c:162 rename_ref: refs/heads/bla -> > > refs/heads/blub "Branch: renamed refs/heads/bla to refs/heads/blub": 0 > > > > $ GIT_TRACE_REFS=1 git reflog show refs/heads/blub > > 12:04:23.277805 refs/debug.c:294 reflog_ent refs/heads/blub > > (ret 0): cd3e606211bb1cf8bc57f7d76bab98cc17a150bc -> > > cd3e606211bb1cf8bc57f7d76bab98cc17a150bc, Han-Wen Nienhuys > > <hanwen@xxxxxxxxxx> 1637751839 "Branch: renamed refs/heads/bla to > > refs/heads/blub > > " > > > >> I think the rule for "msg" is that: > >> > >> a multi-line message, or a message on a single incomplete-line, > >> are normalized into a single complete line, and callback gets a > >> single complete line. > >> > > > > That is not how it works today. The files backend verbatimly dumps the > > message supplied to it. (Maybe it should crash if there is a '\n' in > > the message). > > I still am puzzled what you wanted to illustrate with the "git > branch -m bla" trace. I'm trying to illustrate that (from the perspective of the ref backend API) one call inserts something without a '\n', but the call that reads the info back, gets the same data back with a '\n'. It looks confusing and inconsistent to me. It seems fine to decide that the message should always end in a LF, but then why not do that in the normalization routine, so it is shared across all backends? For the purpose of the debug support (GIT_TRACE_REFS=1), I would rather prefer if the message was always without LF, because the LF ruins the visual of the debug output, but that is a minor concern. -- 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
