Commit message box autofills with whitespace if commit template has comments in it

ghost commented 4 years ago

Issue Type: Bug

Expected Results:

When commit template has comments it in, do not prefill commit message box in "Source Control" panel with whitespace.

Actual Results:

My commit message template has a lot of comments in it but no live text. Before the latest update (1.38 i think), the commit message box would be empty as expected. Now, the commit message box is prefilled with a lot of white space after each commit and when opening the source control panel for the first time. So I have to delete the whitespace each time to enter a proper commit message. If I delete my .gitmessage.txt template, the whitespace does not appear.

The behavior remains when VSCode is run with no extensions.

Below is my .gitmessage.txt file (single empty top line):


# feat: Summarize changes in around 50 characters or less
#
## Whitespace changes are separate!
##
## feat:   new feature for the user, not a new feature for build script
## design: change to the user-facing look but not functionality
## fix:    bug fix for the user, not a fix to a build script
## docs:   changes to the documentation
## perf:   A code change that improves performance
## style:  code formatting, missing semi colons, etc; no production code
##         change
## refactor: refactoring production code, eg. renaming a variable
## test:   adding missing tests, refactoring tests; no production code
##         change
## build:  updating build tasks, package manager configs, etc; no
##         production code change
## ci:     Changes to our CI configuration files and scripts
## 
### <type>(<scope>): <subject>
### 
### <body>
### 
### <footer>
## 
## fix: a commit of the type fix patches a bug in your codebase (this
## correlates with PATCH in semantic versioning).
## 
## feat: a commit of the type feat introduces a new feature to the
## codebase (this correlates with MINOR in semantic versioning).
## 
## BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the
## beginning of its optional body or footer section introduces a
## breaking API change (correlating with MAJOR in semantic versioning).
## A breaking change can be part of commits of any type.
## 
## Others: commit types other than fix: and feat: are allowed, for
## example commitlint-config-conventional (based on the the Angular
## convention) recommends chore:, docs:, style:, refactor:, perf:,
## test:, and others. We also recommend improvement for commits that
## improve a current implementation without adding a new feature or
## fixing a bug. Notice these types are not mandated by the conventional
## commits specification, and have no implicit effect in semantic
## versioning (unless they include a BREAKING CHANGE, which is NOT
## recommended). 
## 
## A scope may be provided to a commit’s type, to provide additional
## contextual information and is contained within parenthesis, e.g.,
## feat(parser): add ability to parse arrays.
## 
## Example <scope> values:
##   init
##   runner
##   watcher
##   config
##   web-server
##   proxy
##   etc.
## 
## The <scope> can be empty (e.g. if the change is a global or difficult
## to assign to a single component), in which case the parentheses are
## omitted. In smaller projects such as plugins, the <scope> is empty.
## 
# More detailed explanatory text, if necessary. Wrap it to about 72 
# characters or so. In some contexts, the first line is treated as the 
# subject of the commit and the rest of the text as the body. The
# blank line separating the summary from the body is critical (unless
# you omit the body entirely); various tools like `log`, `shortlog`
# and `rebase` can get confused if you run the two together.
# 
# Explain the problem that this commit is solving. Focus on why you
# are making this change as opposed to how (the code explains that).
# Are there side effects or other unintuitive consequences of this
# change? Here's the place to explain them.
# 
# Further paragraphs come after blank lines.
# 
#  - Bullet points are okay, too
# 
#  - Typically a hyphen or asterisk is used for the bullet, preceded
#    by a single space, with blank lines in between, but conventions
#    vary here
# 
# If you use an issue tracker, put references to them at the bottom,
# like this:
# 
# Closes: #123, #234
# Resolves: #123
# See also: #456, #789

VS Code version: Code 1.38.1 (b37e54c98e1a74ba89e03073e5a3761284e3ffb0, 2019-09-11T13:35:15.005Z) OS version: Windows_NT x64 10.0.18362

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz (8 x 2904)| |GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
oop_rasterization: disabled_off
protected_video_decode: enabled
rasterization: enabled
skia_deferred_display_list: disabled_off
skia_renderer: disabled_off
surface_synchronization: enabled_on
video_decode: enabled
viz_display_compositor: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.85GB (17.14GB free)| |Process Argv|| |Screen Reader|no| |VM|0%|

Extensions (52)

Extension|Author (truncated)|Version ---|---|--- html-snippets|abu|0.2.1 TabOut|alb|0.1.6 project-manager|ale|10.8.0 arepl|alm|1.0.17 gitstash|art|3.1.0 language-hugo-vscode|bud|1.1.0 better-toml|bun|0.3.2 path-intellisense|chr|1.4.2 bracket-pair-colorizer|Coe|1.0.61 vscode-markdownlint|Dav|0.30.2 ini-for-vscode|Dav|0.0.4 vscode-quick-select|dba|0.2.8 githistory|don|0.4.6 vscode-babel-coloring|dza|0.0.4 gitlens|eam|10.0.1 vscode-html-css|ecm|0.2.3 vscode-great-icons|emm|2.1.47 auto-close-tag|for|0.5.6 auto-rename-tag|for|0.1.0 matlab|Gim|1.3.0 reg|ion|1.0.1 vscode-edit-csv|jan|0.1.4 auto-comment-blocks|kev|1.0.1 wrapSelection|kon|0.6.8 contextualduplicate|laf|0.2.0 vs-color-picker|lih|1.0.0 copy-github-url|mat|0.2.0 markdown-shortcuts|mdi|0.11.0 git-graph|mhu|1.16.0 code-beautifier|mic|2.3.3 python|ms-|2019.9.34911 remote-wsl|ms-|0.39.5 csharp|ms-|1.21.3 Go|ms-|0.11.6 vsliveshare|ms-|1.0.869 color-highlight|nau|2.3.0 indent-rainbow|ode|7.4.0 gitpatch|par|0.2.1 vscode-print|pdc|0.7.12 material-icon-theme|PKi|3.9.0 vscode-css-peek|pra|3.0.2 code-settings-sync|Sha|3.4.3 vscode-autohotkey|sle|0.2.2 vba|spe|1.2.0 css-auto-prefix|spo|0.1.7 rewrap|stk|1.9.1 code-spell-checker|str|1.7.18 unique-window-colors|stu|1.0.51 vscode-open-in-github|sys|1.13.0 shell-launcher|Tyr|0.3.0 sort-lines|Tyr|1.8.0 vscode-icons|vsc|9.4.0 (10 theme extensions excluded)

ghost commented 4 years ago

Might have something to do with this recent commit? Seems unlikely but it's possible.

https://github.com/microsoft/vscode/pull/80335/files/4b90d9ba82a3b7340139990dde9db87874a0ac44#diff-344b8481439db2d9949984cbd9332879

joaomoreno commented 4 years ago

https://github.com/microsoft/vscode/issues/80415

ghost commented 4 years ago

Thank you @joaomoreno

ghost commented 4 years ago

@joaomoreno I just received the 1.40 update where this behavior was changed. In some sense, I guess it's behaving as intended, and in another sense, it's not what I was hoping for. Now, in the commit message box, it shows the full content of my .gitmessage file, all the commented out lines and everything. What I really meant originally and wanted (can't speak for others of course) is for the commit message box to not print any comments. Only print uncommented text. If I do an interactive commit message from the command line, my commented template will pop up and that's all fine. But for the tiny commit message box, I definitely do not want that to have anything in there other than what is absolutely necessary, which for me, is only uncommented text... which in this case, means the message box would be empty. This was the behavior before 1.38 or 1.37.

If it's going to stay this way, perhaps a settings switch to either ignore the gitmessage file for the integrated commit message box, or only render uncommented text, or render the whole thing (as it does now).

joaomoreno commented 4 years ago

Yeah, I was thinking the same once I pushed the changes. I think we should do that setting yet it would mean: populate the input box with the template commit message without any comments. What do you think?

ghost commented 4 years ago

Yea, to me that makes the most sense. That way if you want something in there, then you have it uncommented. Otherwise, it will be completely blank as if there was no gitmessage file.

joaomoreno commented 4 years ago

@gaetawoo https://github.com/microsoft/vscode/issues/84274

ghost commented 4 years ago

Thank you!

microsoft / vscode

Commit message box autofills with whitespace if commit template has comments in it #81569

Expected Results:

Actual Results: