Vscode: 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.

[eaz120]

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.

[stkb]

Closing this now as the original query has been answered, and I agree an easy way to write commit messages in a full editor would be better.

[medikoo]

Closing this now as the original query has been answered

@stkb since which version it's in VS Code? On my side I actually don't see that feature.

[stkb]

@medikoo It was answered in the sense that vscode now gives a warning if the message is too long and it was explained why automatic wrapping was too problematic to implement.

Since I see from upthread that you disagree with that, I've re-opened.

[medikoo]

@stkb yes, just warning doesn't help much and real solution is definitely possible. Great thanks for reopening

[xogeny]

Just a comment (since this is still open). I've actually been quite frustrated by the commit message box in VSCode. I'm surprised more people aren't commenting on this, but it really does seem odd that commit messages are edited in a sidebar. I understand auto-wrap may be problematic in some languages, but couldn't you just disable it for those language? It seems a bit strange to not implement a feature that the vast majority of users would benefit from just because some wouldn't. But in any case, just something that visually indicates overstepping the 72 character convention would be useful. I saw this this and thought, "Perfect! And it doesn't matter to me if it is implemented as an extension." only to realize that that is an extension for Visual Studio, not Visual Studio Code.

Bottom line: I agree that this is a frustrating aspects of an otherwise excellent editor.

[pkazmier]

@xogeny Agreed, we should not be using the sidebar for commit messages. I’m floored that there isn’t as much noise about the integrated Git commit message box or the fact that lines aren’t wrapped. Like others, I can’t use VScode to commit as every project I’m on has rules on line length.

_The irony of the situation is that we haven’t found a good solution on how to edit a Git commit message in the world’s best editor!_

[stkb]

As I've said above, I'd like this to be simplified, but really it's easy enough to commit from the integrated terminal so that it opens a 2nd instance of vscode where you can do all the formatting and wrapping you like. I only use the sidebar for very quick/temporary commit messages.

[mbiegert]

As multiple others are "floored" by the low noise here, I'd like to add my two cents here:
As @stkb pointed out the integrated commit box is really useful for quick commits containing only a few words. However, as it is recommended to write detailed commit messages, the tiny commit box on the left pane does not seem fit for this purpose. Even if it would hard break the lines as suggested in the original post.
On the other hand I very much like the git pane: It helps in staging the right files, review your changes, etc. I'd therefore vote for streamlininge the workflow @stkb seems to have established for himself: Upon committing with an empty commit message (using the checkmark in the git pane) an editor window in vscode should open where you can write your commit and which automatically (and visually) wraps your lines as you type the text.

[xogeny]

@mbiegert I agree. Even though I am quite proficient with the git command line, like you I really like the sidebar. It is just the treatment given to the commit message I'm disappointed by.

An approach that opens a tab in the editor for the commit message would be fine for me.

Another idea which I failed to mention in my previous post. What if the Git pane resized itself when the commit message had focus? That way, the Git pane would be minimal and sit nicely on the side when you were looking at code, comparing things, etc. But the moment you actually focus on the commit message it expands to something that can accommodate the 50/72 rule? Then, when the commit has been made or focus has been dropped, it returns to its previous size.

It seems so simple, it almost makes me want to write it as an extension. But never having written a VSCode extension before and being too busy at the moment, I'll have to defer that for now. 😞

[acdha]

This seems a lot more useful now that the commit dialog will nag about long lines but doesn't offer any way to fix the message except manually wrapping the text yourself. I end up using vim in a terminal window since the experience is so much better.

[oliversalzburg]

I end up using vim in a terminal window since the experience is so much better.

That pretty much sums it up for me as well.

[jkodroff]

Would like to put in my two cents if I may. Here's how I would design the commit inputs (moving from a single textbox to 2 separate inputs:

1. Textbox
   
   
   
   • Required
   
   
   • Hint: Enter a summary of your commit here
   
   
   • Max length 50 with inline character counter
   
   
2. Textarea
   
   
   
   • Optional
   
   
   • Hint: Enter more detailed explanatory text if necessary. Use blank lines to break paragraphs. Use hyphens for bullet points
   
   
   • Automatically (forcibly) wraps content at 72 characters per line
   
   

Optionally include a link to detailed guidelines for good git commit messages, e.g. https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53

Optionally include an option to go back to the old single input textbox since people get upset when you move their cheese, possibly to be removed eventually.

I think the UI I describe above should be the default as we want to steer users towards writing quality commit messages.

Apologies in advance for my ignorance of a11y, i18n concerns as well as the capabilities of Code's UI components - I'm just a regular old user with a feature request.

The main use case I'm thinking of is that I recommend Code to ops folks who are brand new to infrastructure as code. Many of them have never used an IDE/fancy text editor at all, let alone git. So in order to get them writing good commit messages, I have to advise them to install an additional tool (Sourcetree, GH Desktop, or similar) in order to make it easy for them to write good commit messages.

[JerkyTreats]

Hey sorry if this has already been discussed, this thread is long in the tooth.

Can we make the commit body not warn for line length, or better yet make it optional? I only care about the _first_ line being too long, latter lines Im fine with.

[tstivers1990]

Perhaps this should go in a separate issue. But I feel the commit textbox should be using monospace font by default as well. This would allow for adding a ruler to the box as an additional option.

[medikoo]

Generally it should probably work as:

• Title: Warn on 50 (should be customisable)
• Description: Autobreak (detect and insert purely "\n" as new line char) to not exceed 72 chars (that length could also be customisable)

I still wonder why it's so hard to autobreak, afaik some other editors do it well.

[madig]

Atom breaks lines by itself by default in recent versions, you can turn that off by clicking a small icon in the commit text field. This would be nice to have.

[HookyQR]

My preference:

1. Commit message box renders in fixed width font (the user's editor font would be perfect)
2. Same warning exists for first line.
3. Window shows a (optional) ruler at the 72 character point. (or a settable value)
4. I can take or leave the 72 character warning, because it doesn't tell me what character I'm at anyway, so finding the right point to go back and hit enter is annoying.

[ssbarnea]

Is there a way to enforce the 50/72 rule with vscode? Somehow I have the impression that if you setup vscode as your git editor, it would break well formatted messages by auto-unwrapping the message.

[waynew]

Is it possible to just have a setting "auto wrap git commit messages"?

That would solve the problem of breaking behavior when committing in non-ascii text, as well as allow the rest of the world to have the behavior they want. Win win?

I would turn that on right now if it existed. Ship by default with it off (or maybe use LANG to see if it's en_ something and turn it on).

Personally, I'd probably just want a warning on the first line, I'd love for it to force a blank second line, and then wrap the other lines at spaces if there's more than 72 characters.

In my dream, I'm typing my summary and I hit 50 characters it would give me a warning like it does right now for the 72 lines, so I can decide if I want to keep with the limit or maybe I have a darn good reason.

Then I hit enter and I simply cannot edit the second line (or maybe make the UI like GitHub's, with a separate box). Then I start typing in the next box and as soon as I hit 72 characters it goes back to the previous space and puts a newline there instead. Then I type a bit more and paste in a URL, and then it doesn't wrap that one, because it's a URL and it's long because the Internet.

But I hit space and start typing and it drops to the next line, and I finish up and then I'm done and hit ctrl+enter and it submits my commit like it always does.

Any questions?

[iancanderson]

What @waynew describes is exactly what I want and expect (warning for commit "title", auto-wrapping for description)

[JamesYFC]

Warning-wise, it seems like we used to have the 50 part of the "50/72 rule", and now we only have the 72 part.
The first line now only warns at 72 chars, not 50 -- at least on the windows version.

This doubles as a mini warning for anyone else who quickly control-backspaces after seeing the warning without reading it, while assuming that it hasn't changed from 50 characters, like I did...

[fatcerberus]

The current warning is nice to have, but I find it kind of annoying since it just tells you you're X characters over the limit without actually showing you where the line break should have gone. This makes for a lot of wasted time after I've typed almost a whole sentence before noticing the warning and now have to figure out by trial and error where I should put the line break...

The ideal solution for me would be just to allow me to type a message "naturally", using soft wrapping only (which also makes it easier to review before submitting) and apply the 72-column hard wrap automatically when actually making the commit. This is what the old version of GitHub Desktop used to do and a feature I really miss in their new client.

[Peeja]

This is also what magit does by default. (Or rather, it adds hard breaks as you go, but the end result is that you don't have to work for it.)

[Kinrany]

For me the biggest pain is that the "X characters over 72" warning is hard to predict. This breaks my flow. With a ruler I would insert newlines on the fly, but right now I have to stop typing and go back to fix the warning.

Resizing the sidebar to be 72 characters wide would be an acceptable makeshift solution, but the font is not monospaced.

[adab4d]

For me the biggest pain is that the "X characters over 72" warning is hard to predict. This breaks my flow. With a ruler I would insert newlines on the fly, but right now I have to stop typing and go back to fix the warning.
Resizing the sidebar to be 72 characters wide would be an acceptable makeshift solution, but the font is not monospaced.

I create a new window on the fly, switch the language to git-commit and write there the message. In settings.json I have:

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

This breaks the flows a bit as well but I prefer having visual guidance.

[CombeeMike]

I'm also having struggle with the max length in the commit editor. What I'd like to see is short & simple:

• Monospaced font
• 2 rulers at the Input Validation Length & Input Validation Subject Length setting...

This would improve the "write commit message" experience quite tremendously for me!

Edit

I've created a dedicated issue #93150 since I felt that the request is not "well placed" here...

[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.