Depends. If the number points to a very well written ticket, that’s fine.
We work with Jira and Github and all the bugs/features are explained in Jira tickets. I’m not staying long enough in this company to see them changing from Jira to something else, so I don’t care about the Jira dependence to understand commits.
The git log should still stand on its own. The ticketing platform could get migrated in a way ticket numbers are not kept or old tickets are a bit less convenient to find, or just temporarily down.
When working on the code, it's also very useful to access the history without having to open each ticket. Being able to hover a line, having the message of the commit which last changed it, and be able to say "ah ok, it was for this" is quite useful.
> I’m not staying long enough in this company to see them changing from Jira to something else, so I don’t care about the Jira dependence to understand commits
Isn't this a terrible argument in favor of "Fixes NNN" commits? Someone who care about the longevity of a versioned thing should care. If you don't care anyway, nothing matters much.
I don't know about the "git log should stand on its own". Chances are that when you finally migrate to another ticketing system and the ticket numbers in your commits "break" or become meaningless, you do not care much about that old history anyway.
And even if someone is interested in an old commit that contains a ticket number for a ticketing system that does not exist anymore, the commit itself (the code changes, not the message) tell the story as well, just not in prose.
It's pretty common with configuration or infrastructure as code that a blame brings me to a commit from 5-6 years previous, where I wish to understand why the authors at the time made a specific decision.
That is more than enough time to change ticketing system, wiki platforms, or collaborative chat services.
Fair enough, I did not think about the IaC space when I wrote the comment. And I can absolutely see how a blame could take you to commits from a few years back.
I was only thinking about the application code space where elaborate code comments are definitely more common.
> Being able to hover a line, having the message of the commit which last changed it, and be able to say "ah ok, it was for this" is quite useful.
Honestly, this just sounds like we need better integrations with JIRA into dev tools. I'm not going to rewrite tickets in commits / PRs. That ticket has its own history, linked tickets, acceptance criteria, epics, related bug tickets, etc.
Copy-pasting the title of the ticket into the commit title is not much. Or editing the title of the ticket at commit time when everything is clearer.
But indeed, you could imagine some script that fetches the ticket title / content from the ticket number and commits. Nice weekend or hackaton project.
