Hi there! Interesting idea, I've been thinking something like that for a long time, but my chosen IDE solved it most of the times for me. I was working with Eclipse and JIRA in the past on Java projects. I could read the issues inside Eclipse, activate one at a time and then when I clicked commit, it auto-filled the message with the subject of the task and the task Id. Found it very useful until it was supported, as I had only one source of task descriptions and they got reflected in everywhere else.
As for your approach, I would think twice how much information it has to read "Updated two files" in the commit message when any decent git client shows you this information when comparing commits. I'd rather connect it to the issue manager to fetch the subjects automatically.
Edit: I like to read the "why" in the commit message, not the "what".
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.
Hi there! Interesting idea, I've been thinking something like that for a long time, but my chosen IDE solved it most of the times for me. I was working with Eclipse and JIRA in the past on Java projects. I could read the issues inside Eclipse, activate one at a time and then when I clicked commit, it auto-filled the message with the subject of the task and the task Id. Found it very useful until it was supported, as I had only one source of task descriptions and they got reflected in everywhere else.
As for your approach, I would think twice how much information it has to read "Updated two files" in the commit message when any decent git client shows you this information when comparing commits. I'd rather connect it to the issue manager to fetch the subjects automatically.
Edit: I like to read the "why" in the commit message, not the "what".
totally agree
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".