Auto-wrap removed text from commit message

[Arcanemagus]

Prerequisites

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

Description

If you are writing a commit message that includes # at the start of one of the "words" (such as referencing an issue/PR), and it just happens that the commit message automatically wraps to that being at the start of the line, that entire line is removed from the commit message with no explanation as to what happened.

Steps to Reproduce

1. Write a commit message that has a (the last?) line starting with # when wrapped.
2. Commit the commit.

Expected behavior:

The commit message to fully show in the final commit, regardless of how it gets wrapped.

Actual behavior:

The commit message was wrapped like the following:

trace: built-in: git 'commit' '--cleanup=strip' '-m' 'Move cpy-cli to a devDependency

The `cpy-cli` dependency is only used in the `compile` script (which is
called by `prepublish`), as such it should have been a `devDependency`
from the start but was mistakenly added as a regular `dependency` in
#280. This moves it to where it should have been.'

This lead to the #280. This moves it to where it should have been. part disappearing from the message.

Reproduces how often:

100% of the time that the message fits this profile.

Versions

OS: Windows 10 x64 Enterprise

Atom    : 1.26.0-beta1
Electron: 1.7.11
Chrome  : 58.0.3029.110
Node    : 7.9.0
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.26.0-beta1
python 2.7.14
git 2.17.0.windows.1
visual studio 2015

Additional Information

This ended up in a commit like atom/text-buffer@cb63ce5 as I didn't notice until after it was pushed up that the last part was missing.

[Arcanemagus]

After talking to @kuychaco a bit about this, currently the proposed solution is:

• When the user is editing in "full mode" assume they knew what they were doing when they began a line with # and leave it as is.
• When committing from the mini editor enable the --cleanup=whitespace option.

The mini-editor mode will also need to strip the comments from merge messages which seems like it should be okay since the content wouldn't make it into the final commit message anyway, and is already shown to the user in the rest of the Git panel's view.

---

The "full editor" mode is intended to be as raw as possible, so the --cleanup option shouldn't be specified at all. This will normally default to default mode, which in this case would be strip, however if the user has changed their commit.cleanup option it would be respected here.

The mini-editor being forced to --cleanup=whitespace will only trim whitespace from the start and end of the commit message, allowing any # that happen to get wrapped to the start of a line to be preserved (along with the rest of that line!).

Some concerns:

• Will this behavior be intuitive enough?

[smashwilson]

After playing around with it a little, I ended up doing basically the reverse with the --cleanup options:

1. When the user is editing in "full mode," respect the commit.cleanup config option if it's set to a non-default value. Otherwise, use strip, which trims whitespace and comment lines.
2. When committing from the mini editor, use verbose and commit as-is to avoid problems caused by hard-wrapping like this one.

My logic is that "full mode" feels more like the command-line flow of composing a commit message in your ${EDITOR}. The editor uses the git commit message grammar, so # lines are greyed out, which gives you a visual cue about what the message will look like, etc. Committing with the mini editor feels more like doing a quick -m which doesn't apply any preprocessing by default.