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.
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.
That is more than enough time to change ticketing system, wiki platforms, or collaborative chat services.
I was only thinking about the application code space where elaborate code comments are definitely more common.
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.
But indeed, you could imagine some script that fetches the ticket title / content from the ticket number and commits. Nice weekend or hackaton project.
For new contributors it's probably also more useful to see the latest snapshot of the code base and code comments than having to check a git log in order to find out why a function would be written in the way it is.
Sometimes you need to go back and read through a lot of context understanding why a block of code does what it does, and it's a lot more efficient for the rest of the time to have a quick reference to the full explanation rather than pages of comments giving that context.