I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
My issue is not so much in the viewing, as I can get to the diff or list of files changed after a commit. It's more about the friction of writing.
I get that you prefer the "why", but the case I am solving for is where the why is immaterial or self-evident. For example when I am making doc changes - I am happy to lose the nuance of whether I fixed a link or added an empty line or changed a heading level because it's not code. Or it's a change made to follow a style. Or renaming a file because I like the new name better.
"It's more about the friction of writing." - I totally understand why it can be tedious to write meaningful commit messages every time. I admit I'm guilty myself of writing messages like "fixed". By writing "fixed formatting" we get more context than one file changed.
When you will come back to your code sometime later, you will scratch your head, and you will have an extra round every time comparing two versions of the file to capture what happened and why. If you feel the need to reflect something that is already captured by git then just leave the comment empty. That's a bad habit as well, but sometimes you are really just doing things like: "fix: type-o".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for your feedback.
I found an approach native to git for prefilling a ticket number in a commit message and wrote about it here if you are interested.
My issue is not so much in the viewing, as I can get to the diff or list of files changed after a commit. It's more about the friction of writing.
I get that you prefer the "why", but the case I am solving for is where the why is immaterial or self-evident. For example when I am making doc changes - I am happy to lose the nuance of whether I fixed a link or added an empty line or changed a heading level because it's not code. Or it's a change made to follow a style. Or renaming a file because I like the new name better.
"It's more about the friction of writing." - I totally understand why it can be tedious to write meaningful commit messages every time. I admit I'm guilty myself of writing messages like "fixed". By writing "fixed formatting" we get more context than one file changed.
When you will come back to your code sometime later, you will scratch your head, and you will have an extra round every time comparing two versions of the file to capture what happened and why. If you feel the need to reflect something that is already captured by git then just leave the comment empty. That's a bad habit as well, but sometimes you are really just doing things like: "fix: type-o".