vscode: Git input validation got broken in 1.85.0
Type: Bug
The git commit message input validation coloring and messages no longer show up. This was working a couple days ago, and stopped working when the editor auto-upgraded to v1.85.0.
Repro steps:
- Launch VSCode in a git repo.
- with or without extensions enabled; it repros either way.
- Click Source Control in the Activity Bar.
- Type a long commit message.
Expected:
- In the first line, characters past the
git.inputValidationSubjectLengthlength should be highlighted in red, as they used to be. - In subsequent lines, if the current line is longer than
git.inputValidationLengththen a message should be shown in the Message box indicating the number of extra characters past the validation length.
Actual:
- No highlighting, no overflow message.
It’s like the git input validation feature has been completely removed. I didn’t see anything in the release notes about that, and the settings still exist, so it seems like an unintentional regression.
My git input validation length settings are the following:
"git.inputValidationLength": 72,
"git.inputValidationSubjectLength": 50,
VS Code version: Code 1.85.0 (af28b32d7e553898b2a91af498b1fb666fdebe0c, 2023-12-06T20:48:09.019Z) OS version: Windows_NT x64 10.0.19045 Modes:
System Info
| Item | Value |
|---|---|
| CPUs | Intel® Core™ i7-10870H CPU @ 2.20GHz (16 x 2208) |
| GPU Status | 2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled |
| Load (avg) | undefined |
| Memory (System) | 31.77GB (19.22GB free) |
| Process Argv | . --crash-reporter-id e22f69dd-b5d3-447a-b7b6-02eceab1bad6 |
| Screen Reader | no |
| VM | 0% |
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vslsvsres303:30308271
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30899288
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
azure-dev_surveyone:30548225
3biah626:30602489
f6dab269:30613381
2i9eh265:30646982
showlangstatbar:30737416
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
welcomedialogc:30910334
pythonnosmt12:30797651
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
dsvsc013:30795093
dsvsc014:30804076
dsvsc015:30845448
pythontestfixt:30902429
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:30885898
pythontbext0:30879054
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
aa_t_chat:30882232
dsvsc019:30917259
About this issue
- Original URL
- State: open
- Created 7 months ago
- Reactions: 40
- Comments: 32 (9 by maintainers)
Oh interesting. Yeah, the changing of that default could have been handled/communicated a little better probably.
Some feedback, then:
This is a weird default to want to change to off. Wouldn’t it be better to have the default to ‘warn’ like previous to nudge people to follow the standard? I know when I first started I did not know git commit messages usually have a 50 character first line. Without this I would be blasting huge commit messages everywhere.
Does https://github.com/microsoft/vscode/issues/185606#issuecomment-1840655597 help?
@lszomoru changed defaults are often controversial and if this didn’t get called out prominently in release notes it’s even more likely to catch people out.
I actually preferred the previous dismissable message box as displayed in the image below, thanks to this SO post for the image.
It was always on display as a reminder. As @chrisant996 pointed out the new squiggle underline takes time to hover over it, to even see what’s wrong with it. The squiggle doesn’t immediately convey the error. It could be any kind of error, like a spelling error etc.
What’s very strange to me is that this change has only occurred recently, at least for me. I’m pretty sure I saw the old message box just last week. And what’s more, it is very unprofessional to change the UI very suddenly without warning, or consulting it’s users via the software’s interface (not everyone keeps updated on these issues!).
There was absolutely nothing wrong with the message box, and I highly recommend you reinstate it. If you want, make it an option to change the styling of error, letting us users decide whether to use the message box or the awful (in my opinion) squiggle underline.
This is a matter of being a good git citizen.
It doesn’t make sense why vscode has changed to use different defaults than git itself does.
If the issue was that the warning UI wasn’t up to standards, then a preferable fix would be to improve the UI (e.g. any of the ways that have been discussed in this issue). Turning off the validation goes too far and is counter productive in the bigger picture of being a good git citizen.
I strongly agree that the default setting should be restored.
Encountered the same issue. Set
or
solves my issue.
@chrisant996, thank you very much for filing this issue. We did indeed change the default setting for validation in the latest release. I agree that I should have done a better job and documenting the change. I will make sure to update the release notes retroactively so that others can find the change more easily.
As far as the current validation UI, I do agree with all of you that it is less than ideal that it overlaps the primary action button. Since the commit message input is a full-fledged Monaco editor, I have been exploring using diagnostics information in order to signal a validation error (see the existing UI vs. the one based on diagnostics):
Please bring the message box back 🙏
The default setting was “warn”, right? It’s beneficial to remind developers to summarise their commit title to less than 50 (or another reasonable length) so the title can be fully displayed everywhere without ellipsis. It also helps display a clean and neat commit log when you do
git log --oneline. The length validation and warning message don’t block us from doing more explanation in the commit body.VS code is widely used, I think this default setting is instructive for most developers. If VS code doesn’t do this validation by default there will be more and more people writing long commit messages which are difficult to read.
@lszomoru why did the team make this decision to change the default setting of this?
I prefer the display a warning box under the commit input box either. I’m using Code Spell Checker it can help me correct the typos in the commit message.
As you can see, it marks the typo with a wavy line. But the new style overrides the Code Spell Checker and I have to move my mouse over the line to read the warning message.
Displaying a warning box in the area might not be the best solution however it works for a long time and is pretty handy.
Yes. But when
alwaysis chosen, the UI metaphor is broken, as has been mentioned in other issues.Instead of the validation message in a floating box that covers other buttons (unfriendly to mouse users), the Commit Message box itself should expand to make room for the validation message box to be contained entirely within the Commit Message box.
What were the problems with the warning message box that led to removing it?
I think the following would be nice:
I’m confused. This issue reported that a setting’s default changed unexpectedly. How come you’re asking for feedback on a new implementation of the setting under this issue’s comments? Maybe I’m misunderstanding something. Does the new implementation address the concern this issue was trying to bring up? Has the default value been reverted to its expected value (
warn)?Edit: Got it! Didn’t realize the new feature was a blocker for this issue.
The
git.experimental.inputValidationsetting has been removed and the new diagnostics-based input validation can be enabled using thegit.inputValidation. Give the new input validation a try and let me know your feedback.@lszomoru For the past couple of months, I have been tearing my hair out why does the commit validation not work anymore? I have finally found a StackOverflow post relating to this which explained that this has been turned off. I am very happy to have it back on. FWIW Entire teams are using this feature to write better commit messages that help others understand the changes faster without having to look at the diff. This setting has been enabled by default for years, so why change it? I will be very grateful if the default
warnwill be brought back. VSCode is such a fantastic IDE and this feature is absolutely amazing. I had feedback from other developers who have been literally taught by VSCode to write better commit messages thanks to this feature. Once again thank you for the development of VSCode.@lszomoru If it’s a full-fledged Monaco editor, would it be possible to render ruler lines at the git input validation widths?
Not only that, but this would also enable us to create a “code action” to wrap the text.