Commit fails with "error: switch `m' requires a value" if commit message starts with hash sign #

[mcferden]

trafficstars

Version info

• OS: Windows 10
• Build: 2063

Description

Commit fails with "error: switch `m' requires a value" if commit message starts with hash sign #

Steps to reproduce

Steps to reproduce the behavior:

1. Open repository with some changes
2. Enter commit message starting with #
3. Run commit command

Expected behavior

Commit command runs successfully.

[srbs]

likely caused by #1214

[mcferden]

I'd suggest the app ideally should respect commit.cleanup git setting.

[dpjohnst]

Hi @mcferden,

Thank you for reporting this issue - as @srbs mentioned, we recently updated the commit dialog to remove comments when committing to match Git behavior. That being said, the logic doesn't take into account the commit.cleanup setting currently as you've noted.

I will be adding support for this setting so that it's available in the next build.

In the meantime the quickest workaround would be to set the git config value core.commentChar, which would override the default Git comment character.

E.g. run the git command git config core.commentChar ";" which would set the comment character as ;

Thanks for your patience while we resolve this.

Cheers, - Dylan

[srbs]

the app [..] should respect commit.cleanup git setting.

the git config value core.commentChar

Every time I turn around, I learn about another git setting. 🤷‍♂️ (note: I'm not a sublime dev)

[mikevaux]

E.g. run the git command git config core.commentChar ; which would set the comment character as ;

Thanks for the heads up about the workaround! I believe you need to quote the character though, e.g. git config core.commentChar ";"

[mcferden]

I'd suggest the app ideally should respect commit.cleanup git setting.

Also I think # should be ignored for single-line commit messages anyway.

[abjugard]

Typing this here since my issue was closed.

Since the character # actually has a use in many development platforms like Azure DevOps, GitHub, GitLab, etc, we can't just delete message lines users have typed starting with it. There are several good solutions here I think.

Why not detect if a user has manually started a line with # and automatically run the command with the flag --cleanup=whitespace in those instances for example?

Or how about adding that flag depending on which commit flow we are in? So if we are in a merge flow (where the field is pre-populated by git) then we don't add that flag (but make it clear that comments will be escaped through syntax highlighting), but if we are just committing normally, where users are just typing the messages, then we add that flag?

There is another cleanup mode which looks like it could be helpful here depending on how smerge pre-populates the commit message box in certain flows, --cleanup=scissors. If it isn't the git binary that pre-populates merge commit messages then perhaps the stuff we want to ensure isn't added to the message could be placed after a scissor-line?

Ultimately I'm fine with any solution where smerge doesn't remove any lines that I have typed from my commit messages. Or are we seriously expecting people to be typing comments while they are typing a commit message? I find that laughable.

[alecgibson]

I don't know if I'm the only one who did this, but I was also using # as markdown syntax for headers. For example, Github will automatically parse commit messages into Pull Request descriptions, and it supports markdown for this.

Treating # as comments now means my commit message headers get stripped.

[abjugard]

Can we get an update on what's happening with this?

[abjugard]

Like, I understand the reasoning behind respecting # as a comment character, but when we enter a commit message in your editor, it's not the same as when $EDITOR is called by git in the terminal window, and it isn't bound by the restrictions that apply there.