Github: Error when commit message begins with a hash (#)

[ol1s]

Prerequisites

[x] Have you tried to reproduce the problem in Safe Mode?
[x] Have you followed all applicable steps in the debugging guide?
[x] Have you checked the FAQs on the message board for common solutions?
[x] Have you checked that your issue isn't already filed?

Description

Cannot commit using a message that starts with a hash (#)

Error message received is:

Aborting commit due to empty commit message.

Steps to Reproduce

1. Open GIT panel
2. Stage changes
3. Enter commit message starting with hash (#)
4. Click commit
5. Error message (as above)

Expected behavior:

Expect to be able to commit with a message starting with a hash (#). It is useful to be able to do this if referencing a support ticket ID for instance.

Actual behavior:

Presumably it is thinking that this commit message is a comment.

Reproduces how often:

Every time

Versions

ATOM 1.18.0
github package 0.3.3
Windows Windows NT 10.0

[rsese]

I can reproduce with Atom 1.18.0 on macOS 10.12.5 - thanks for the report @OS16X :v:

[NickWhiu]

same here on linux with github v0.3.3 & atom v1.19.0-beta1 x64

[BinaryMuse]

This is an interesting issue. This actually fairly closely matches Git's default behavior, which is to clean up the message when created through an editor:

Strip leading and trailing empty lines, trailing whitespace, commentary and collapse consecutive empty lines.

Normally one could opt out of this behavior by setting commit.cleanup to verbatim or one of the other options, but because we pass the message via -F and -m instead of allowing Git to do its normal commit editing thing, we have to do our own pre-processing of the commit message.

To be frank, removing comment lines by default is desired behavior any time Git's commit templates are used, such as when resolving a merge conflict, so it's unlikely we'll simply remove the feature. However, I'd certainly be interested in finding a good way to have the package respect the commit.cleanup setting, or adding a setting inside Atom itself to control this behavior.

Thoughts? 💭

/cc @kuychaco

[rsese]

which is to clean up the message when created through an editor:

Ohhhhh I had tested locally outside of Atom with just git commit -m #test but I didn't do it with just git commit and then through an editor where I would have seen the same message.

[miles-smith]

Having quickly dug through the source code, is it possible to respect the Git _core.commentchar_ setting rather than hardcoding/relying on the default _'#'_ value in the comment stripping regex?

[liam-b]

Hmm, I'm having the same problem. Just switched over to this package instead of command line and ran into this :(

[liam-b]

If you want to be able to start commits with hashes:
Run apm develop github
Go to .atom/dev/packages/github
Change line 611 of lib/models/repository-states/present.js from const messageWithoutComments = message.replace(/^#.*$/mg, '').trim(); to const messageWithoutComments = message.trim();
Run atom in dev mode :)

[SleepWalker]

@rsese so can this package provide the support of config.commentChar or it is something, that goes against philosophy of this package?

[Sidnioulz]

I believe this bug is fixed on Atom 1.27.2? I appear able to make commits starting with '#' so long as my ~/.gitconfig has commentChar set to something else. Could someone else please try to reproduce the bug after using the following command?

git config --global core.commentchar "%"

[smashwilson]

Oh, this should be fixed by #1500, which will be included in atom/github v0.17.0 / Atom 1.29.0-beta0. We had a few issues related to commit message processing and I must have missed this one.

[jnawk]

problem exists with Ubuntu 20.04.1 LTS, Atom 1.49.0, git 2.25.1

User should not have to change config to get functionality which already exists (eg, git commit -m '#962 comment referring to github issue 962')

Perhaps GitHub and Git need to have a fight where GitHub loses and introduces a new way to refer to issues in commit messages?