[brian_cunnie]

> Regarding migrating to new issue tracking systems, "not maintaining history" is absolutely a critical fail at that org

Sometimes it's not a critical fail; sometimes it's a permissions issue: only a small subset of developers have access to the original ticket.

The fix is simple: write good commit messages. Don't assume the person reading the commit message has access to the ticket.

[hn_throwaway_99]

It's still a critical fail, and it's not like you can blame not properly migrating your ticketing system on someone not having permissions. And in practice, I find the opposite to be true: many more stakeholders with necessary reason to see the state of an issue are likely to have access to the issue tracking system than source control.

But more importantly, this thread somehow got off the rails into a debate about only leaving a ticket ID in the commit. I never argued for that, and I don't think anyone else did either. A commit message should still state what happened, code-wise, in a particular commit (e.g. one ticket may require many commits or PRs). But I still think the ticket ID is the most important piece of info in the message, as it ties the commit to important context about why the code change was made in the first place.

[Nullabillity]

Or... fix your permissions issue.