Feature Request: commit message length warning

[decoyjoe]

There's a convention that the line length of commit messages should be limited to 50/72 characters.

Both VSCode (git.inputValidationLength) and Vim (gitcommitSummary) have features where the editor will warn you when the length of the current line of the commit message is greater than a configured limit.

It would be nice if lazygit had this same functionality where a warning will be displayed in the commit message input prompt if the current line length is greater than the configuration setting commitLengthWarning: <int>.

[GMkonan]

Totally agree, I think it can be really simple like I have in zsh where the commit message starts getting red characters when you pass 72 chars.

[GMkonan]

I can create a PR for this later since I already have made the commit on my fork, people interested can check the changes here:

• master...GMkonan:commit-message-length-warning

[Xevion]

Is anyone interested in opening this issue back up?

About 2 years since the issue's creation, and more than a year since the PR was created by @GMkonan. Coming up on a year since the last comment.

[stigkj]

Yeah, I would like to have this feature too. Now I edit the commit message in another git client before pushing 😜

[stefanhaller]

Please give #3173 a try then, I think it's much better than what's proposed here.

[thisisrandy]

I came here looking for a way to visual denote when the summary line is longer than a fixed length, which I'm used to seeing in vim (the color becomes paler after a configurable length). It turns out that <c-o>e from the commit message menu allows me to edit the message in my editor, which in my case gets me the functionality I want for free. Of course lazygit also has the character counter on the summary box, but if your editor is more fully-featured than lazyvim, consider bringing it up for editing.

[ChrisMcD1]

/close

With the merging of #3173, it is now trivial to not write overly long commit messages, since the lines now wrap by default. Feel free to re-open if you think that is insufficient.

[niklasravnsborg]

Hi there, @ChrisMcD1 I would actually prefer to not wrap my commit message (I deactivated autoWrapCommitMessage), but I would still like to get alerted, if my message is to long. Maybe that would be a usecase for this feature request? ☺️ Thank you

[stefanhaller]

I would actually prefer to not wrap my commit message (I deactivated autoWrapCommitMessage),

@niklasravnsborg I'm curious why, can you explain? I can't think of a reason to disable this.

but I would still like to get alerted, if my message is to long.

You can install a commit-msg hook to check for long lines (e.g. like this). This is better than building it into lazygit, because it also works when you commit outside of lazygit (on the command line, or using some other client).

[niklasravnsborg]

@stefanhaller My personal reason was this longer description on a recent commit in my dotfiles repo. When viewed on a small screen size (e.g., on mobile or in a slim terminal), the lines break in an unnatural way. I wasn't aware that lazygit added these newlines, so I turned them off.

The other reason is that I don't want the title of a commit to accidentally break into the description of it. But as far as I can see, the autoWrapCommitMessage is not active on the commit title anyway, so even with autoWrapCommitMessage turned on, my title (first line of commit message) will not be wrapped - only the "Commit description", as lazygit refers to it.

If that information and my testing are correct, I think the autoWrapCommitMessage doesn't even solve the original aim of this feature request. @ChrisMcD1 @decoyjoe

[stefanhaller]

When viewed on a small screen size (e.g., on mobile or in a slim terminal), the lines break in an unnatural way.

Sure, that's a general problem with commit messages that are wrapped into paragraphs. I don't think that leaving them unwrapped is a solution though, because there are clients that don't wrap at display time (e.g. gitk), and having to scroll horizontally to read a long paragraph is way worse than looking at the doubly wrapped text on a small display. But that's just my personal opinion, and you might disagree.

However, if you want to leave long paragraphs unwrapped so that they are better readable on small displays, then I don't understand why you want a warning about long lines.

But as far as I can see, the autoWrapCommitMessage is not active on the commit title anyway, so even with autoWrapCommitMessage turned on, my title (first line of commit message) will not be wrapped - only the "Commit description", as lazygit refers to it.

That's true.

If that information and my testing are correct, the autoWrapCommitMessage doesn't even solve the original aim of this feature request. @ChrisMcD1 @decoyjoe

The thinking was that the warning would only be needed for the body; the subject already has the character count at the top right, and we thought that's enough to tell whether you are above or below the limit. Some clients turn the characters red that exceed the limit, and I agree that this would be nice, but it would require some changes to gocui, so it's not trivial to do. And so far I thought it's not worth the effort.

[niklasravnsborg]

Thank you for your in depth answer!

However, if you want to leave long paragraphs unwrapped so that they are better readable on small displays, then I don't understand why you want a warning about long lines.

For me it would just be a small UX quality-of-life benefit that would raise my awareness if the title length is not optimal. Once I know, I usually make the effort to try to reformulate the commit message and make it more concise.

The thinking was that the warning would only be needed for the body; the subject already has the character count at the top right, and we thought that's enough to tell whether you are above or below the limit. Some clients turn the characters red that exceed the limit, and I agree that this would be nice, but it would require some changes to gocui, so it's not trivial to do. And so far I thought it's not worth the effort.

Yes, I thought of something like changing the color of characters over the limit or displaying a more pronounced character counter "[title length: 75]" when it is over 72—similar to how gitui does it.

I understand that this feature might not be a priority right now.