When writing commit messages I'm missing the following information (at 1 glance):
How much more can I write in the current line?
This is kind of available by the "x characters left message" but I find it easier to recognize a line which is "coming closer" than a decreasing written number.
Do all lines of a multi line commit meet the desired max line length?
I can already move the cursor through all lines and wait for the "validator" to turn orange or stay green but I find that very laborious mainly for 2 reasons:
Input Validation Length & Input Validation Subject LengthI see that this is at least related to #2718 but created a dedicated request since I'm not looking for any "auto correction" but only a better visual guidance.
I also just noticed that the textbox performs a "auto wrap" which is quite troublesome to me since this wrap is no real line separator but only a "visual wrap" which in turn makes it even harder to realize how long the line really is...
I've therefore added a 3rd point to my "solution" above...
I 100% agree.
Auto wrapping is bad if the author did an 80 char alignment. This turns this (which is wrong but not terrible)
word word word word word word word word word word word word word word 72word w80
word word word word word word word word word word word word word word 72word w80
word word word word word word word word word word word word word word 72word w80
into this which reads very bad:
word word word word word word word word word word word word word word 72
word w80
word word word word word word word word word word word word word word 72
word w80
word word word word word word word word word word word word word word 72
word w80
I additionally propose to enforce these rules:
From here: https://chris.beams.io/posts/git-commit/
(Sorry, did not want to hijack your request)
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding
:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
Just want to add a +1. I came here with the explicit intent of creating a feature request just like this. Glad I'm not the only one who desires it.
I will say that finding this was very challenging, I nearly filed a bug report of my own simply because it's difficult to express in words what it was I was after. Searching bugs specifically for "git ruler" is what found it. I suspect there would be much more support for this feature with higher visibility/easier discoverability.
@ChadBailey What did you search for first? Adding this "keywords" might help others find this :)
That's a valid suggestion, however, I think the problem mostly existed in my head lol. I didn't actually try a whole lot of search terms, but went through lots of combinations in my head before deciding on searching open issues for "git ruler" since i figured those were the two most unique terms to this problem.
That said, I looked up my initial search (on Bing) which was vscode git commit reason ruler . This resulted in so many unrelated results I was sure that further searches would be futile lol.
Most helpful comment
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!