Git - Automatically insert line breaks in git commit messages

[stkb]

I'm trying to get into the habit of writing good commit messages. Not sure if this should be the default but it would be really useful if vscode automatically wrapped commit message lines at say 80 chars and inserted line breaks.

I don't mean changing the appearance of the text in the commit message box, just before it's actually committed. The line length could be in an option too.

[joaomoreno]

How about a little UI that would tell you that some lines are over 80 characters, and you'd format them yourself? Would that work?

[stkb]

@joaomoreno Maybe, and actually that was my first thought, though these points came to mind:

• It might be difficult to do without cluttering up the currently nice and clean UI
• It might look weird/be difficult to format the text given that the comment box uses a variable width and not a monospaced font.
• If it was on by default, some people might not like in it a "I don't care/stop telling me what to do" kind of way.
• Having the wrapping done automatically is easier for you than having to do it manually anyway, and in special cases where you need to do it manually you can still do so.

Overall I felt that just inserting hard line breaks before committing would be easier, though it does mean writing or finding the code to do the word-wrapping (not sure what the policy is on using external js libraries). There could be a setting something like "git.commentLineLength" with a default 0 (no word wrap) so no-one gets any unexpected behavior.

In any case if it's wanted it is something I'm prepared to work on.

[joaomoreno]

Good points.

As for the UI, I was thinking something like what you get when you try to rename a file to / in the explorer. I would't use the red color but something smoother, that doesn't sound such a big alarm. I would also put it behind an enablement setting.

I would like to stay away from automatic wrapping, since it might not do what the user intends to do. Also, we'd have to make it work for non-latin languages too: Arabic, Japanese, Chinese, etc. Not a trivial task.

There's a double edge sword in automatic wrapping: turning it on by default would be transparent to the user and, if the outcome is not desirable, he will only detect that when it's too late, probably when the commit was pushed to his server. If we set it off by default, we risk that no one will find and/or use it.

What do you think?

[stkb]

This is an effect used in Github Desktop, as well as elsewhere.

Although here the effect is a bit too subtle; I find it a bit difficult to see the limit. In Twitter it's much more visible.

Something between the two would be really neat, and maybe with the right balance it could be on by default.

However I don't know if the edit box is capable of that kind of rich text, so failing that, yeah the popup that comes up when entering an invalid filename is also nice and that would be ok (as you say, in a less flashy color).

[arirawr]

@joaomoreno Anyone working on this? I'm happy to give it a look.

[joaomoreno]

Actually we already have this:

[nomicos]

@joaomoreno That is a tooltip addressing the first line of the commit message. But I think the proposal described in this issue was about having Visual Studio Code automatically wrap the commit message body to 72 characters per line (the 50/72 convention). In that case, the user's only worry would be the message itself, with VSC wrapping it right after they click 'Commit' and before the actual commit is made.

[stkb]

@nomicos That was my original wish, yes, but as @joaomoreno pointed out, vscode has to support a lot of languages and correct automatic wrapping in non-latin languages can be really hard. (Eg in vietnamese I think they don't have spaces and you basically have to use a dictionary to know where to break the text.) It's really out of the scope of vscode.

What I now do when writing a long commit message, is compose it in blank editor and then copy-paste it in to the commit message box. I would like to see a feature that streamlined this process a bit though.

[jimmyharris]

I can understand how this might be beyond the scope of the editor but would it be possible to add a tooltip that tells you when you go over the 72 character length on the next line? The 50/72 commit message guideline is almost universal and it would be nice if we could follow it without the extra step of having to edit the commit message after the fact.

Alternatively is there a reason we couldn't make the commit message window more like an editor window? There are plugins for automated line wrapping that currently cannot be accessed in the commit message window. It would be excellent if we could access them inside the commit message window.

[medikoo]

@stkb @joaomoreno

vscode has to support a lot of languages and correct automatic wrapping in non-latin languages can be really hard.

I think it would be totally ok if it'll work purely with spaces as we use them writing English.

Programming and writing commit messages in English is common approach worldwide, no matter where are you from, and what is your native language. So providing support for all written languages in that specific case seems an overkill.

[joaomoreno]

From @rmunn

---

• VSCode Version: 1.10.2
• OS Version: Linux Mint 18 (based on Ubuntu Xenial 16.04.2)

I'm asking for #2718 to be reopened, or for further discussion on the feature to be had in this issue. #2718 was closed because wrapping arbitrary-language text is really difficult (e.g., Thai has no spaces between words, and there is no algorithmic way to correctly break lines in between words; you have to have a Thai dictionary built into your program if you want correct linebreaks in Thai). However, there are two factors that make this an unimportant consideration for Git commit messages:

1. Any programming team that has more than one native language among the programmers in the team has probably already standardized on a single language, and that language is almost always English where spaces between words are normal.

2. There are very good reasons for NOT splitting lines in commit messages if those lines do not contain spaces, because those lines are probably URLs.

So the rule for Git commit message word wrapping should be very simple:

1. First line warns if it's more than 50 columns. (This is the current behavior).
2. Second line warns if it isn't blank.
3. Rest of the commit wraps on spaces (or on any whitespace, but I recommend sticking with plain 0x20 space characters only for simplicity) at a user-configurable column, defaulting to 72 since that's the current standard recommended by Git.
4. Any line in the commit that does NOT contain spaces does not wrap, but a warning pops up (similar to the warning if the first line is > 50 columns) saying "Your commit message contains # long line(s) which could not be wrapped because they do not contain spaces. If these lines are URLs, that's probably okay, but otherwise you should consider adding spaces so that the lines can be wrapped. Your settings are currently set to wrap any lines longer than 72 characters in your commit message." (With #, of course, being substituted for the actual number of too-long lines in the message.)
5. That warning can be disabled in the user or workspace config settings, for the sake of any teams who have standardized on languages like Thai which do not use spaces in the language. The word-wrapping behavior can also be completely disabled if the user so desires, but it starts configured to be ON.
6. (Optional). If the long line starts with the regex [a-zA-Z][-a-zA-Z+.]+: (see RFC 3986), it is assumed to be a URL and no warning is issued for that line, since it's usually not desirable to split a URL across two or more lines.

This would go a long way towards making VS Code's Git message editor usable. As of right now, I avoid using VS Code's Git integration because it doesn't format Git messages correctly according to the coding standards of just about every project I've worked on. So despite the fact that VS Code has pretty good Git integration for most things, I still just Alt-Tab to a terminal and write my Git commits in Vim, where I can set it up to do the right thing for commit messages (wrap at 72 columns, or at 70 for one project I work on that has slightly stricter rules than most).

P.S. Also, as a side effect, I'd like to ask that the Git commit window NOT visually wrap lines that aren't truly wrapped (e.g., the only thing that causes text to go to the next line in the commit window is a real linefeed or CR/LF in the commit message). Instead, if the text goes past the end of the available window size, give us a horizontal scrollbar, which will serve as a cue to resize the Git sidebar to be large enough to fit 72 characters horizontally. And perhaps also there could a button that will automatically resize the Git sidebar to fit the text already in the commit message -- though that's a more "bells and whistles" feature, rather than core functionality.

[rmunn]

Note that my proposal is close to what @stkb originally asked for when he opened this feature request, but there is one specific part of my proposal that is the opposite of what he asked for. He said he wanted the appearance of the Git commit message window to not change, and for the returns or linefeeds to be inserted ("silently", so to speak) after the message composition is finished. Whereas what I am proposing is that the wrapping be visually obvious, so that it's clear precisely where your text is going to be wrapped. This is basically a different proposal, which is why I originally opened a new issue to track it. But we might as well discuss it here, where interested people are already subscribed.

[e-segev]

VS Code version 1.14.2

I think the commit message box is terrible and very limiting for such an important feature
(entering detailed message, that is) and renders the integrated GIT unusable for me.

I use Sublime instead, where a text file is opened and I may enter conveniently a detailed message
in any format I wish.

I'm not sure why it is difficult to do the same here.

[TrevorBurnham]

@eaz120 I've requested this feature at #30562.

[VeteranCoder]

Hello everybody. Since this issue remains open, I'd like to throw in my observations and a suggestion.

I generally don't commit with VS Code precisely because of this input box. It leaves me unsure of the appearance of the end result when viewed online or in another IDE. I'd like the box to accurately reflect the format, and perhaps expand automatically while editing to look more like a typical editor.

I usually use GitEye for all my repository work for several reasons (and the list shrinks as integrations improve).

First, I have a full-screen view of the state of my repository, its layout is pleasing, and I get a "visual" sense of the state of my branches, history, and pending work. Second, it is written in Java so I can use it on Windows and Linux. Third (and the part relevant here), is the "Git Files" view - specifically the commit message box.

It warns when there is no empty line after first, but doesn't have a separate wrap length from the rest of the text. The example below is a single line of text pasted into the editor. I added only a linefeed after the first line. Wrapping is automatic, and a grey line identifies the wrap point. When committed, the text looks exactly as it did when writing it.

If the panel is narrower than the wrap, it will wrap the lines in the editor, then break at the proper location, so it doesn't look great. Simply widening the view automatically gets it to what is shown below. This is an open-source project, so developers here might want to take a look at the code and see if it can be translated to VS Code in a useful way.

[elieux]

We can now set monospace font in v1.46.

[austinorth]

I would just like to chime in here to echo @waynew . I have been automatically wrapping the body of my commit message to keep lines at 72 characters or less when I author a commit in terminal, and it makes things quick and easy. I don't have to think about what word I'm going to put on the previous line as opposed to the next line. This is a small calculation that I really never want to ever have to think about. As a newer user of VSCode, it was jarring to me that this functionality doesn't exist! 😞 So it would be so nice to just have a lil' setting that allowed you to turn this on. 🙏🏻

[aradalvand]

No updates on this one?

[lszomoru]

There is currently a pull request which would add the capability to use the editor for authoring a commit message. The pull request leverages some vscode API that is currently being finalised but as soon as that happens we should be able to make progress on the pull request.

[marcusrbrown]

I noticed the PR was merged a few days ago. Congrats!

Is there anything else preventing this issue from being closed?

[lszomoru]

@marcusrbrown, I had to revert the change until I fix couple of issues with it. I hope to be able to commit it today.

[buondevid]

Automatic wrapping (subject and/or body) in the Commit Input field on the top-left is still not available, right?

[dvnrsn]

Yes, we could use a configuration option automatically_wrap_git_commit_message at 50 and 72 because some of us write long commits and have to often adjust them and it's a pain to have to readjust every line once editing something toward the top.

Edit: I found rewrap combined with #95266 to get me pretty close to what I want. First line has red over 50. All other lines wrap. Maybe there is a way to get perfect with wrapping to rulers but 95% was good enough for me

settings.json

  "[git-commit]": {
    "rewrap.autoWrap.enabled": true,
    "rewrap.wrappingColumn": 72
  }

Note: Might need to command palette: Rewrap Toggle auto wrap to wake it up.

[lszomoru]

Using the complete editor to author commit messages is now part of VS Code.
Using the full editor enables configuring editor rulers and wrapping so I will go ahead and close this feature request.

  "[git-commit]": {
    "editor.rulers": [
      72,
      50
    ],
    "editor.wordWrap": "wordWrapColumn",
    "editor.wordWrapColumn": 72
  }

[buondevid]

Nothing for the commit box in the top-left corner? An automatic wrapping option would be very appreciated. See my previous comment.

[zarembas]

I started using the commit command because of this issue, but to be honest now I prefer it to the input box.

[zarembas]

Setting the rules from a previous message

  "[git-commit]": {
    "editor.rulers": [
      72,
      50
    ],
    "editor.wordWrap": "wordWrapColumn",
    "editor.wordWrapColumn": 72
  }

is not working as expected.

It wraps the commit message to 72 characters, but it doesn't add newlines, so after you commit, the message won't be wrapped.

[lszomoru]

Today's VS Code Insiders release (version details below) contains a new setting, git.experimental.inputValidation ,to enable a new implementation of input validation for the commit input field that uses language diagnostics. Using diagnostics also enabled us to implement quick fixes (ex: hard wrap long lines). Enable the new setting, and try out the hard wrap code action and let me know what you think. Thanks!

Version: 1.87.0-insider (Universal)
Commit: 01f46bb5357baa8f3b9da690e1e34eb78e09a72b
Date: 2024-02-12T05:48:37.277Z
Electron: 27.3.1
ElectronBuildId: 26731440
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin arm64 23.3.0

[buondevid]

In the new VSCode release (1.87) there is a setting that can be enabled now both for subject and message 👌

[justingrant]

I'm running 1.87.0 (not insiders) but I'm not seeing any line breaks inserted in my commit message when it goes over the limit. Expected? Here's a screenshot illustrating the problem.

[dvnrsn]

@justingrant yeah it's only a validation warning (which is working on yours). If you want it to auto wrap as you type you'll need to use something like rewrap and the full editor (see my comment above). afaict that's the only way to do this in vs code as of yet.

[justingrant]

@dvnrsn the previous VS Code release had a setting where you could see the number of chars in the field as you were typing. This stopped working in the current release. Is there a way to re-enable it?

I'm asking because it was much more convenient to know when the limit was coming, because then I could proactively hit Enter to move to the next line. With that feature removed, now I had to wait until I see the yellow warning squiggle, then back up and remove the last word, then press Enter. That's a lot more unnecessary extra typing.

One possible solution could be a small countdown timer like Twitter uses. Like this?