git commit --verbose
However, VSCode doesn't seem to support that commit mode out of the box. Perhaps it could be the fallback behavior if you run one of the Git: Commit commands and enter a blank commit message. (Currently, that fails silently.) Or better yet, how about a git.verboseCommit setting that, set to true, would make the Git: Commit commands take me directly to the verbose commit editor?
          
I'll repost my comment from #2718 (comment) where I asked for some specific features for the Git commit message editor (whether it's in a full editor window or not, though being in a full editor window would probably make it easier to implement this request):
... [T]he rule for Git commit message word wrapping should be very simple:
First line warns if it's more than 50 columns. (This is the current behavior).
Second line warns if it isn't blank.
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.
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.)
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.
(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).
          
@rmunn I'm not sure about bringing the issue of automatic wrapping up again in here in this issue that isn't really about it, though I see that you may have commented here because I'd closed #2718, which I've now re-opened.
Something I've learned from writing stkb/Rewrap is that wrapping isn't as simple as you'd first think and people have all sorts of requirements (ok, like just about every project then).
My workflow currently is to go the source control pane and look through the file diffs, then if it's a short commit message just type it in the box there, but it it's longer run git commit from the built-in terminal, which brings up a new vscode window where I have rulers set up at 50 and 72 columns and can use Rewrap to wrap the contents and check how it looks before committing.
So I don't see the need to use Vim, you can set up vscode as your git editor and for me it works fine. It would be nice if there was a faster way to switch to a full editor for the commit message, but I'd only put it in the "nice to have" category rather than essential.
          
Any news on whether this will be implemented? I really like VSCode's Git workflow but I like the commit message style from Atom. I think this could be implemented as an option on commit so that, instead of showing the one-liner text box, it shows a fully fleshed editor (ideally as a split panel) using git commit --verbose. One of the advantages is that all rulers and autocomplete extensions that you add to the editor would be available.
Currently I'm using the run-in-terminal extension with a shortcut tied to a custom script that reproduces the behaviour of VSCode's commit. It works but not always quickly and seems like an overkill.
Add support for git commit verbose
Git: Support editing the commit message in a text editor
    Sep 18, 2018
Currently I'm using the run-in-terminal extension with a shortcut tied to a custom script that reproduces the behaviour of VSCode's commit. It works but not always quickly and seems like an overkill.
@albireox would you mind sharing the implementation of that script? Do you do something other than shelling out to git commit --verbose, and have code set as your default Git editor?
          
The "script" I link to run-in-terminal is a simple fish shell function such as
function commit -d "Commits staged or all files"
    set result (eval "git diff --name-only --cached")
    if test -n "$result"
        git commit -v
        git commit -v -a
It basically checks if something has been staged and if not it commits everything.
          
hi, @joaomoreno from what you wrote in #43585 I would like to add that in our company we want to help juniors write good commit messages. It not only helps understand what commits were about but more importantly makes juniors think about the work they have done and most often we found that they go back to edit the commit. For example by splitting them into two or actually rewriting the code because they notice a single responsibility issue. To help them with this process we use git's template feature. This is what our template looks like in case you are curious.
I think it would be great if the warnings that are displayed in the VSCode's source control side-bar at the moment could also be shown in the editor. The auto-wrapping is of course even better but just the warning would also be a great benefit.
# 50-character subject line
# 72-character wrapped longer description. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# Include a link to the ticket, if any.
# Add co-authors if you worked on this code with others:
# Co-authored-by: Full Name <email@example.com>
# Co-authored-by: Full Name <email@example.com>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch address_picker
# Changes to be committed:
#	modified:   src/
# Changes not staged for commit:
#	modified:   package.json
#	modified:   src/
          
Funny enough, I sometimes end up going to the terminal and running git commit so I'd have a proper editor for my commit message.
@joaomoreno can you update the community on the status of this?
@TrevorBurnham Thanks for the --verbose that's going to be helpful :)
          
Regarding the closed issue:
Most people don't really want a full editor taking away workbench space. They just want to type a message and move on.
I'd argue that isn't the case. You try submitting a quick one-liner message to any large project...
          
We are looking at using VS code for the Linux kernel. Commit messages typically run 20-70 lines long and generally require complex editing tasks like text reflow, copy & paste, careful indenting and managing the git tags list at the end. The tiny commit dialog is totally inadaquate for this task, it is required to have a fully featured editor.
Here are some examples of what is expected:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28f94a44298c99c0db85539874b62f21d94fcaa7

(requires wrapping paragraphs)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc52d9140aa920d8d61c7f6de3fff5fea6692ea9

(requires manging indending and cut&paste alot of text)
          
This is not working for me in Insiders. If I enable
"git.verboseCommit": true,
"git.useEditorAsCommitInput": true
and try to commit I get an error
Git: '/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/extensions/git/dist/scripts/git-editor.sh': /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/extensions/git/dist/scripts/git-editor.sh: No such file or directory
It seems there's a typo in the path. The correct one should be /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/extensions/git/dist/gitEditor/scripts/. However, if I try to create the dist/scripts/ directory and symlink git-editor.sh from the correct location, I get this error
[2022-05-26T15:51:35.065Z] error: There was a problem with the editor ''/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/extensions/git/dist/scripts/git-editor.sh''.
Please supply the message using either -m or -F option.
          
Quick update on this. While we have ironed out all issues that were identified, we simply ran out of time for this change to be included in the May 2022 milestone. The changes will be committed to the main branch as soon as it opens up for the June 2022 milestone work. I will update this issue as soon as the changes are released in Insiders. Thank you very much for your patience.
          
Today's Insiders release (2022-06-10) contains the changes to use the editor for the git commit input. You can enable this capability using the git.useEditorAsCommitInput. After enabling the setting you will have to restart VS Code so that the GIT_EDITOR environment variable is set. Give it a try and let me know if you run into any issues.
Thanks again to @JohnnyCrazy for his contribution as well as to all of you for your patience.
          
Starting with today's Insiders release (2022-06-17) we have made two changes:
git.useEditorAsCommitInput is now enabled by default
Added a new setting, git.terminalGitEditor, so that users can opt out when running git commit commands in the integrated terminal
          
Gosh here we go again... why are you people so obsessed with constantly changing defaults settings?? I have had vim for years and suddenly something changes and I have just wasted half an hour of my time trying to work out what to change to bring it back as it has been for years.
Pro TIP: unless you are fixing something that was breaking DON'T. CHANGE. DEFAULT. SETTINGS.
Thanks
  alterae, 1Mark, AlekSi, ionut-botizan, albireox, theAkito, and CyanBook reacted with thumbs up emoji
  happyteque reacted with thumbs down emoji
      All reactions
          
If Vim is "horrifying" to you, I suggest a career switch to organic farming. What an arrogant smartarse
Every change breaks someone's workflow, which is why you should keep to a minimum unless you are solving a real problem. You weren't.
Pro TIP: unless you are fixing something that was breaking DON'T. CHANGE. DEFAULT. SETTINGS.
Maybe it isn't broken for you, but it is for users who are not comfortable with vim. Furthermore, being able to act as the default editor for git commit messages, we are now in the fortunate position to be able to provide additional value (think issue completion, author completion, semantic versioning linting, etc.).
Additionally it's not synced, so now I have to manually go and change it on every machine I use... 🙄
Feel free to enable Settings Sync.
@happyteque One more thing: please think twice about arbitrarily offending people online. Just because there's hardware between you and another person, doesn't mean you can be impolite.
          
I understand why some people may like it, I am only objecting to the defaults changing for everyone, @joaomoreno.

Git itself handled such changes better - when they enforced merge strategies, they started showing a message on every merge telling people they now had a new option and had to make a choice. The message also told them what their options were. Whereas you guys just changed one of the settings without warning nor explanations. It's not the first time you do this, I still remember the train wreck whith the Terminal panels suddenly not being movable to the right anymore.
As for @segevfiner, he was the one out of line with his sarcastic, snappy reply. Perhaps you should have words with him, but I understand it's easier to gang up on ${WEIRD_STRANGER}.
If Vim is "horrifying" to you, I suggest a career switch to organic farming. What an arrogant smartarse
Thank you for appropriately assessing your own behaviour. This way, nobody has to tell you, how you sound.
Every change breaks someone's workflow, which is why you should keep to a minimum unless you are solving a real problem. You weren't.
Obviously, there was a real issue, hence this issue. Additionally, if you are heating up your spacebar for years and think that's alright, then that does not mean nobody should break that behaviour. If you are doing it wrong for years, it's time, since years, to change your wrong behaviour.
All that you said in this issue is basically just a psychological defense mechanism, which automatically kicked and has only the purpose of making you look less like an arrogant dumbass. You are not being honest. You are not trying to find the truth or debate honestly about what is better. You just childishly came here -- initially caused by your wrongful assumption, that nothing will ever change and everything will ever stay the same with software, which evolves on a monthly basis -- and try to fart your fault out of your arse onto others, because you got used to heating up your spacebar for pressing the control button.
If you are not being able to adjust to improvements in your software tools, you should probably switch to a job, which is already fully optimised. However, do not switch to any type of farming, because there you would need to constantly adjust to new methods and technical possibilities, too. They use pretty high-tech machines there, nowadays.
I am only objecting to the defaults changing for everyone
The same criticism you already read applies the same way to defaults. If a default is crap, it should be changed. Simple as that. Just because you are still stuck in the terminal in this specific situation, that does not mean everyone is and wants to be.
Whereas you guys just changed one of the settings without warning nor explanations. It's not the first time you do this, I still remember the train wreck whith the Terminal panels suddenly not being movable to the right anymore.
Actually, I have experienced the same. Do you know what I do then? I read the most recent changelog, perhaps even CTRL+F for a keyword and there is my result. All clear now. Takes like two minutes in total.
he was the one out of line with his sarcastic, snappy reply.
It wasn't sarcastic, though. You do the same as the guy heating up his spacebar. It's literally a description of what you were complaining about.
I understand it's easier to gang up on ${WEIRD_STRANGER}.
Again, one of those psychologically caused fallacies for mindlessly defending oneself.

In case it makes you happier:
I am just another VS Code user who followed this issue for such a long time. Was waiting for a fix, as many others did. Now you came here with your smartarse attitude and made it seem like this was a bad change, just because you want to keep heating up your spacebar. So, I thought, I am going to tell you what's going on, because you are being simply unfair and absolutely dishonest.
I am sure everyone's really interested in reading @theAkito's vitriolic tome and their personal attacks. @joaomoreno will no doubt scold me for it. It's probably time to lock this issue - I can only repeat the invitation to being more careful with handling default settings changes. As for the deranged comment above, I cannot help but note that @theAkito's mission statement is "Free yourself from yourself". I can see why they'd write that.