Let’s hope the SaaS issue tracker you’re currently using never goes out of business or changes the product in a way that makes it worse for you. Or, if you host your own, that it keeps you satisfied in perpetuity.
Referring to the issue ID in the commit message is a fine practice in addition to writing good, comprehensive commit messages. Commit messages that consists only of an issue ID are – in my experience – utterly frustrating to deal with. They tell you nothing more than this change is somehow related to this or that bug or feature, but not how or why.
So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker?
> writing good, comprehensive commit messages. Commit messages that consists only of an issue ID
Who said anything about only including a tracker id? The issue here is the extra verbosity in the commit message. What will the tracker tickets contain that isn't in your "comprehensive" commit message?
* So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker?*
… Or, and hear me out, how about not worrying about that, and just use your VCS to accomplish something it’s imminently well suited for?
Also, how do you propose I solve the issue of the issue tracking service maybe going out of business or that of a more compelling product coming along?
To me, the primary purpose of an issue tracker is to collaborate on and track work in progress, and that’s what I use them for. I don’t find that they are particularly valuable as historical records of the source code.
Referring to the issue ID in the commit message is a fine practice in addition to writing good, comprehensive commit messages. Commit messages that consists only of an issue ID are – in my experience – utterly frustrating to deal with. They tell you nothing more than this change is somehow related to this or that bug or feature, but not how or why.