I've found that there are mainly two kinds of tickets:
1. The perfunctory kind, where you make the ticket just to track the work, when the work is already obvious and well-known. There's no discussion in the ticket; you just create it, do the work, and close it.
2. The kind where you end up with a lot of back and forth between various stakeholders about what the requirement/feature/whatever is, or about how to reproduce a bug that needs to be fixed, or something like that. In this case, there's a lot to wade through, and while the history can be an interesting artifact as to how everyone got to the end state of the git commit that closed the issue, it's overly wordy.
And sure, there are tickets that are somewhere in between.
But ultimately I think the kinds of tickets that are closer to #1 don't even need a reference in the git commit, because pretty much all of the ticket's text should be in the commit message anyway. And for #2, there's way too much information in the ticket anyway; it should be distilled down to the important details for the commit message. And yes, a reference to the ticket should be provided as well, for people who want or need to wade in to get the full context. But that goes at the end of the commit message, after the change has been adequately described.
> "not maintaining history" is absolutely a critical fail at that org
Absolutely agree! But that doesn't mean it doesn't happen (and often!), and when it does, all your ticket references become useless, so you'd better have a good, thorough description in the commit message, or all context is lost.
> Every decent tracking system I can think of has ways to import issues from other systems
But almost universally you end up with new ticket IDs when that happens, so the references in the commit messages become useless. Sure, many of those importers will start off the description in the imported ticket with something like "Imported from JIRA ID FOO-123", but that requires extra effort to search. Sure, if you migrate from one instance of JIRA to another instance of JIRA, there are ways to keep those links intact/redirected, but I'm not aware of any ticketing system that somehow preserves URLs/IDs from completely different ticketing systems.
> I think the kinds of tickets that are closer to #1 don't even need a reference in the git commit, because pretty much all of the ticket's text should be in the commit message anyway
Not really, because even tickets without body or comments have links. At the minimum, a decently configured tracker must have links to all the other commits involved. And even when there is only one commit, it's useful information unless all tickets in your project are done in exactly one commit.
What if there was another way to handle things like #2? What if you got everyone that needed to be there in the same "room" and had a synchronous conversation in order to resolve all ambiguity?
We don't call them tickets, because we aren't "ticket takers" and we don't expect them to contain all of the information -- how could they, it's our job as implementers to discover and understand. They are work items, and they are placeholders for conversations. We use high-bandwidth communication to reduce, and often eliminate, the "back and forth" that is so common on many teams.
We keep logs of our work both on a personal and project level, which includes decisions from these high-bandwidth conferences. When we have stakeholders that are hard to get meetings with we schedule a regular cadence with them so we can get their time at least once a day/week/whatever.
If you work in a regulated industry (medical, aerospace, auto) you need tracability of all code changes, so even your case 1 needs a ticket reference. Was it a bug? A feature change? Is it linked to requirements? Has it been tested and verified? Which release will it be in?
1. The perfunctory kind, where you make the ticket just to track the work, when the work is already obvious and well-known. There's no discussion in the ticket; you just create it, do the work, and close it.
2. The kind where you end up with a lot of back and forth between various stakeholders about what the requirement/feature/whatever is, or about how to reproduce a bug that needs to be fixed, or something like that. In this case, there's a lot to wade through, and while the history can be an interesting artifact as to how everyone got to the end state of the git commit that closed the issue, it's overly wordy.
And sure, there are tickets that are somewhere in between.
But ultimately I think the kinds of tickets that are closer to #1 don't even need a reference in the git commit, because pretty much all of the ticket's text should be in the commit message anyway. And for #2, there's way too much information in the ticket anyway; it should be distilled down to the important details for the commit message. And yes, a reference to the ticket should be provided as well, for people who want or need to wade in to get the full context. But that goes at the end of the commit message, after the change has been adequately described.
> "not maintaining history" is absolutely a critical fail at that org
Absolutely agree! But that doesn't mean it doesn't happen (and often!), and when it does, all your ticket references become useless, so you'd better have a good, thorough description in the commit message, or all context is lost.
> Every decent tracking system I can think of has ways to import issues from other systems
But almost universally you end up with new ticket IDs when that happens, so the references in the commit messages become useless. Sure, many of those importers will start off the description in the imported ticket with something like "Imported from JIRA ID FOO-123", but that requires extra effort to search. Sure, if you migrate from one instance of JIRA to another instance of JIRA, there are ways to keep those links intact/redirected, but I'm not aware of any ticketing system that somehow preserves URLs/IDs from completely different ticketing systems.