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

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

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.

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.

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.

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)

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

@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"

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.

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

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.

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

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?

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…

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

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)

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.

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.