git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/2] Normalize newlines in merge & interpret-trailer

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 16, 2021, 22:10 UTC
Message-ID
<xmqqsg0dq59v.fsf@gitster.g>
In-Reply-To
<pull.1048.git.git.1626421416.gitgitgadget@gmail.com>
"Luca Weiss via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 12 quoted lines
> These two patches fix a problem where the trailer would be appended to the
> commit message without an empty line, so parsing the trailers again
> afterwards would fail.
>
> In practice either one of the patches fixes the exact behavior I see but in
> both cases it makes sense to normalize the newlines.
>
> The exact use case where this issue was found is a "git merge --no-edit"
> with a commit-msg hook that adds a trailer immediately afterwards. The input
> the commit-msg script gets is not terminated by a newline (which is fixed by
> the second commit) while the first one makes interpret-trailer capable of
> handling such input without a final newline.

When you fold some of what you wrote in the above into the proposed commit log message proper when you send an updated version of the series, please pay special attention to the phrases like "empty line", "normalize newline" and "terminated by a newline".

 - As there are some folks who use Git on Windows on this list, when
   we say "normalize the newlines", they will think of CRLF vs LF,
   but I do not think that is what you are talking about here.
 - As I asked in my review of one of your patches, please explain
   where the incomplete line comes from (e.g. saying "if the user
   ends the edited log message with an incomplete line" would make
   it clear how we missed such an incomplete line to come into the
   system).
 - I am guessing that "without an empty line" is because we usually
   append trailers with one newline after the last line of the log
   message, with the expectation that the existing log message ends
   with a complete line, but an incomplete line at the end of the
   log message absorbs the newline and makes it as part of the last
   line that is now a complete line?  And a trailer block that is
   not separated with a blank line from the last paragraph of the
   message body is not taken as a trailer block, causing the later
   parsing to fail, but from your description it was unclear how
   the trailer block is added without the paragraph break.
Thanks.
Previous: Junio C Hamano
Message 17 of 17 in “Normalize newlines in merge & interpret-trailer”
  1. 0/2 Normalize newlines in merge & interpret-trailerLuca Weiss via GitGitGadget, Jul 16, 2021
  2. 1/2 trailer: handle input without trailing newlineLuca Weiss via GitGitGadget, Jul 16, 2021
  3. Jeff KingJul 16, 2021
  4. 2/2 merge: make sure to terminate message with newlineLuca Weiss via GitGitGadget, Jul 16, 2021
  5. Phillip WoodJul 16, 2021
  6. Luca WeissJul 16, 2021
  7. Phillip WoodJul 16, 2021
  8. Jeff KingJul 16, 2021
  9. Junio C HamanoJul 16, 2021
  10. Jeff KingJul 16, 2021
  11. Junio C HamanoJul 16, 2021
  12. Phillip WoodJul 17, 2021
  13. Jeff KingJul 17, 2021
  14. Luca WeissJul 21, 2021
  15. Luca WeissAug 26, 2021
  16. Junio C HamanoJul 16, 2021
  17. Junio C HamanoJul 16, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.