Should this go into a commit message, instead of an issue/ticket?
FWIW, I also prefer READMEs to Wikis.
Unless you use Fossil :-P. Or for git/hg/svn/cvs/Folder - Copy(43), one of those ticket trackers that work with files inside the repository itself.
What do you mean? Just put an issue ID in the code and/or commit.
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?
… 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.
Porting Jira issues to a different system would probably not preserve those IDs that you entered into your commit message. By all means, refer to your issue tracker in commit messages, but be aware that those references may not be valid in a few years.
> A git repository .. and the commit log and commit hashes stays the same
If issue trackers are so transient and flaky, and VCSs are so solid, then back up your old issue tracker and put it in git. What if your issue tracker stays, but you VCS changes?
In tools like GitHub, if you make a PR with this commit, it will also automatically put the text in the PR description.
I would much prefer this at work over what I usually see with inconsistent commit message styles and not explaining properly what was done, and not following the recommended max length per line.
git log | grep <error message>
git show <commit id>
In a professional setting, companies usually want this information to live in the issue tracker. Mainly to provide insight to managers/other teams without looking at commit messages.
But it removes the information from the code: you now need to look at the issue tracker to make sense of changes, eg when looking at the history of a file, or with git-blame.
I'd argue that all relevant information that affects the code and architecture of the specific repo should live in commits. They should not only tell you what was changed, but also why; and provide enough context to understand the change in the scope of the repo.
All information that is not directly tied to the code, eg cross-repo/product/etc concerns can go in the issue tracker.
Of course this only works well with a `git commit --fixup` and squash + rebase / squash + merge workflow.
And with monorepos it also becomes a tooling problem.
Not really, the commit message can be informative without being this verbose.
> you now need to look at the issue tracker
Doesn't seem like a bad thing to me. Issue trackers are designed to search through.
When a developer is looking at logs for solving some problem, they can easily review the rationale for changes.
I'd much prefer the log explaining everything, rather than having to look to a ticket that may no longer exist.
Why doesn't it? Are closed issues not searchable?
It seems to me you doubt the ticket retention, but instead of fixing that, use commits to store issues instead.
How do you provide comments or updates on an issue "relevant to the commit" without arbitrary commits?
Everywhere I have ever worked has changed ticket systems at one point, and even when they are transferred, the transfer is "lossy".
Heck, just moving from one JIRA version to another can be "lossy".
> How do you provide comments or updates on an issue "relevant to the commit" without arbitrary commits?
In the ticket system. I was not advocating that a ticket system is pointless, because they are very useful.
But a decent commit message about why a change is necessary, especially when it may not be straight forward, can save you plenty of development time further down the line.
If you really need to, put more detailed notes into an "Issues" file for commits/minor releases, and clear it on every major release.
IMO the given example is more verbose that needed. It should give enough information about what and why a fix is done, but no more.
Code, commit logs, tickets, and project management are all part of the same repo with Fossil.
I'd prefer it being on the commit itself.