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

Re: [PATCH] Force new line at end of commit message

From
BHBernt Hansen <bernt@alumni.uwaterloo.ca>
Date
Dec 26, 2007, 17:47 UTC
Message-ID
<87myrxqrev.fsf@gollum.intra.norang.ca>
In-Reply-To
<20071225044202.GO14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 12 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> This is a patch for git-gui, so why not make that clear in the subject?  
>> (And I have a hunch that Shawn would have liked the patch relative to 
>> git-gui.git, not git.git...)
>
> Indeed.
>
> its clear in both the email and in the commit log that the change is
> a git-gui change.  Remember, git-gui's logs show up in the core Git
> logs (as its merged with -s subtree) so having that git-gui: prefix
> does help people to localize the change within the overall suite.
>
Thanks for the feedback on the patch.

This is my first attempt at creating a patch for git (even if it is mostly trivial in this case) and I wasn't aware of the git-gui.gitk repo and conventions regarding the commit message. I just tried to follow what was in Documentation/SubmittingPatches. I'll try to do better next time :)

Show 11 quoted lines
>> Further, there are other tools than rebase -i that like commit messages 
>> better when terminated by a newline, and _that_ is what I would like to 
>> read in the commit message for this patch.
>
> Hmmph.  For that reason alone I'm tempted to *not* apply Bernt's
> patch.
>
> There is nothing that requires that a commit object end with an LF.
> So tools that make this assumption (that there is a trailing LF)
> while processing the body of a commit message are quite simply
> broken.
Forcing a LF on the end of the commit message feels wrong to me too.

This band-aid solution fixes the issue I'm dealing with for git-rebase -i when squashing 3 or more commits created by git-gui.

I agree with Sean and think the more correct fix would be to make git rebase -i and any other tools we encounter with similar problems handle the case where there is no newline at the end of the commit message.

The patch as it stands should probably not be applied.
-Bernt
Previous: Junio C HamanoNext: Shawn O. Pearce
Message 14 of 28 in “git rebase -i / git-gui bug”
  1. Bernt HansenDec 20, 2007
  2. Bernt HansenDec 20, 2007
  3. Reallow git-rebase --interactive --continue if commit is unnecessaryShawn O. Pearce, Dec 20, 2007
  4. Junio C HamanoDec 20, 2007
  5. Shawn O. PearceDec 20, 2007
  6. Junio C HamanoDec 20, 2007
  7. Junio C HamanoDec 26, 2007
  8. Johannes SchindelinDec 29, 2007
  9. Matthieu MoyDec 20, 2007
  10. Force new line at end of commit messageBernt Hansen, Dec 24, 2007
  11. Johannes SchindelinDec 24, 2007
  12. Shawn O. PearceDec 25, 2007
  13. Junio C HamanoDec 25, 2007
  14. Bernt HansenDec 26, 2007
  15. Shawn O. PearceDec 27, 2007
  16. git-gui: Make commit log messages end with a newlineBernt Hansen, Dec 28, 2007
  17. Junio C HamanoDec 26, 2007
  18. Johannes SchindelinDec 29, 2007
  19. Junio C HamanoDec 30, 2007
  20. Johannes SchindelinDec 30, 2007
  21. Junio C HamanoDec 30, 2007
  22. Johannes SchindelinDec 30, 2007
  23. Junio C HamanoDec 30, 2007
  24. しらいしななこDec 30, 2007
  25. Junio C HamanoDec 30, 2007
  26. Junio C HamanoDec 30, 2007
  27. Johannes SchindelinDec 30, 2007
  28. Shawn O. PearceDec 25, 2007

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.