Git: Can't commit if commit message starts with `#`

[daolanfler]

• VSCode Version: 1.40.0
• OS Version: Darwin x64 19.0.0

Steps to Reproduce:

1. make some changes and open source control
2. input a commit msg starts with '#' then press command + enter, nothing happens

This worked fine in version 1.39

Does this issue occur when all extensions are disabled?: Yes

[miluxmilux]

Same here, I am not able to commit at all (with cmd+enter or by clicking the commit icon) if the commit message starts with #. Also on Darwin x64 19.0.0 and VSCode 1.40.0

[joaomoreno]

The fix for https://github.com/microsoft/vscode/issues/6403 made it that the input box now treats lines starting with # as comments. This is a good change since it enables other cool scenarios.

What we need here is better affordance for the user to know what's a comment and what is not: either error/warning messages or a full blown text editor.

[biddster]

Our standards mandate that we prefix our commits with the work item we're working on so the work item is tagged in AZD/GitHub etc.

e.g. #456 did some stuff

...so this change means we'll have to use another git client (or change our standards).

[miluxmilux]

@biddster Same here. Maybe there could be an exception for one-liners starting with # ?

[joaomoreno]

I took @miluxmilux's suggestion and made # one-liners an exception.

[t-denis]

An example of affected message:

#work-item-id with short 50 chars description: 
- more details
- more details

Worked fine, but someday users will find out that their messages have been broken since 1.40. Consider making an alert for such cases, or a preview area, or a settings checkbox, or, at least, color these lines to indicate they will be dropped.

[t-denis]

An exception can be made for #<number> optional text even if there are more than one line.

[dioscuroi]

When will the fix be released? Thanks!

[joaomoreno]

@dioscuroi It will come in the recovery candidate. It's already out on the insider release?

@t-denis Yeah, what I wanna do here is just provide a fully fledged Monaco editor for the commit message. That way we can get coloring and comments will become obvious.

[mendesjorge]

I even post this o twitter but it's best to do it directly here right? (this because no answer was given there) [maybe not your problem but an answer would be enlightening]

source control commit stopped working after last update! (FYI: read all latest relase notes and seems that it wasn't messed up) via @code

— Luís Mendes Jorge (@7wiN69) November 8, 2019

[oBusk]

Shouldn't this be configurable in an option? We prefix our commits with storynumber #1234 and then message, which can be multiple lines. The fix #84273 looks like it will delete the first line of our commits in the future? That's quite the regression...

[joaomoreno]

I'd like to avoid adding an option, since toggling it would simply make other features worse (commit templates, merge commit message restoring). I'd rather improve the editor experience and make it behave like vim behaves: with coloring, decorations, markers, etc.

Hmmm this is actually a much bigger rat hole: https://stackoverflow.com/a/14931661

@oBusk The latest stable release is already deleting lines which start with #. Did you already hit this?

[oBusk]

@joaomoreno In the current release we simply gave up on committing in vscode since we got no feedback why our #1234 Fixed issue with the thing did not work. So we never ran into the issue with the first line being removed. After reading this, yes, I've tested that writing more lines will commit, but remove the first line, like you said.

My thought about the fix is that after that is released, users who use our syntax will most of the time not notice anything, committing as usual (with one line) and then on some commit that requires multiple lines, will all of a sudden see that this commit miss the entire first line. If i didn't read this issue, I'd surely think it is a bug.

Edit: The configurable option I had in mind was to allow # on the first line, but treat as comment otherwise, but looking at your link, it might be more correct to read the current commentChar from the git configuration, as well as copying the behaviour of commentChar "auto"

[DerJacques]

We are in the same boat as @oBusk. All our commit messages need to start with a #ticketId and can potentially span several lines. Right now, we cannot commit using the interface at all.

Would it be possible to syntax highlight the commit message, but not strip it in any way?

To be honest, I’m not sure I understand the upsides of this change yet, but maybe there’s something I’m not seeing.

[jack13]

In general I would expect the message field to behave as same as git command line (git commit -m "#1 Foo").

My current workaround is to simply prefixing it with "task #1 Foo".

This also works for multiple lines and without the need of the above one-liners exception.

In my case (using gitlab) this is good enough to have the references. However when the logic needs to strictly start with the hash then the only workaround is to commit via command line.

[joaomoreno]

This is what filtering out comments enables: https://github.com/microsoft/vscode/issues/6403, https://github.com/microsoft/vscode/issues/75651. It also gets us closer to https://github.com/microsoft/vscode/issues/40295.

I think we're in the right direction, just hitting some bumps. I will push yet another change which will simply allow a # in the first line, which should address most people's use cases. I will then push towards us having a decent editor in there and try to get it out in the November release.

[joaomoreno]

Actually, I will push a change which will allow # followed by numeric characters. This will catch more cases.

[joaomoreno]

Verification:

You should be able to commit a single line starting with # and followed by any contents.

You should be able to commit messages with lines starting with # followed by digits. Lines starting with # and not followed by digits will be commented out. For example, the following commit message:

first line
second line
#third line
# fourth line
# 5th line
#6th line
#7 th line
#8

Should become:

first line
second line
#6th line
#7 th line
#8

Since all other lines should be commented out.

[joaomoreno]

Thanks @RMacfarlane!

[mendesjorge]

Shouldn't I be able do deactivate all that stuff you are trying to do with the commit editor? Me and my team can have a standard for commits that you are blocking with all that regex validations, for sure that will be a -1 on your editor solution (and I will be forced to use sourceTree, I don't like to be forced)

[TheGhost2804]

how is this issue closed when it's not solved?

[af4jm]

if committing to git doesn't behave identically to... type in commit message, select all, go to command line... git commit -m "[paste]"... how could that ever not be a bug! git commit messages are plain text, how could it possibly ever make sense to treat such messages as anything beyond plain text??? stripping lines out of a blob of plain text seems like a solution looking for a problem... even when a file is open of type Git Commit Message or Git Rebase Message, I would expect the behavior to be identical to Plain Text (edited to not use angle brackets around the word paste)

[simonhaenisch]

The "allow number after hash" thing probably covers my use cases, but like @af4jm, I would also expect anything I write in there to end up in the commit message. Can't the solution for #6403 be to just copy the non-comment lines into the commit message field?

I'm surprised that something this crucial would just be changed like that. Crucial in the sense that it's practically impossible to rewrite history in our case, and certain commits are now not linked to an issue because of this regression (that was on 1.40.0, not 1.40.1).

Regression = something worked and now doesn't work anymore, if that's unclear... I don't think it matters whether it worked intentionally or unintentionally, because we as users get used to how it works and expect it to work like that, especially when it comes to version control.

[af4jm]

Suggested solution for the disagreement here...

leave the box in the git sidebar as a pain text box (as it's been working since day 1)... allow the commit button/shortcut to work when that box is empty but pop the git default message in an editor tab, and make the commit when the user closes that tab (and let git handle the filtering of comment lines), satisfying #7830... there could be some hint text in the empty box to tell the user

another option could be a separate shortcut for the editor behavior, but that would have discoverability issues

[joaomoreno]

OK, you've convinced me. Sorry for all the pain.

Let's do this https://github.com/microsoft/vscode/issues/84831. I think the current heuristic is enough to get us through November. I'll disable the whole commenting work in the input box until next release.

[oliversalzburg]

Why was # hardcoded as a comment character in the first place when this is configurable in git?

[joaomoreno]

Everyone, I'm about to push changes to bring the input box back to its original intent: input is now taken literally. Which means comments are now stripped out when restoring git template messages and merge commit messages, until https://github.com/microsoft/vscode/issues/84831 comes.

[liuwenzhuang]

版本: 1.40.2 (system setup) 提交: f359dd69833dd8800b54d458f6d37ab7c78df520 日期: 2019-11-25T14:54:45.096Z Electron: 6.1.5 Chrome: 76.0.3809.146 Node.js: 12.4.0 V8: 7.6.303.31-electron.0 OS: Windows_NT x64 10.0.19025

Now when I type first line start with '#' and follow a blank line and then other lines in commit message input, the first line will be treated as comments, even I have configured commentChar to '/' in git configuration。

[RTS007]

Version: 1.40.2 Commit: f359dd69833dd8800b54d458f6d37ab7c78df520 Date: 2019-11-25T14:54:40.719Z Electron: 6.1.5 Chrome: 76.0.3809.146 Node.js: 12.4.0 V8: 7.6.303.31-electron.0 OS: Linux x64 5.3.12-1-default

I have a vscode set up as a git message writer in gitconfig (editor = code --wait). So far so good. But this month in our company we started using the Phabricator with hashtags, and i cannot use # for comments anymore. I've changed it to | in gitconfig file (commentChar = |) but from now vscode doesn't recognize syntax.

Can I somehow edit syntax highlighting for VS Code? Maybe there is some option to automatically detect the comment char?