2 ms·

While I agree the commit message should summarize what happened in the commit, I pretty strongly disagree that the linkage between git and the ticketing system

While I agree the commit message should summarize what happened in the commit, I pretty strongly disagree that the linkage between git and the ticketing system should not be considered an absolute "first class relationship". There is simply too much information/history to consider that linkage just a "nice to have". Regarding migrating to new issue tracking systems, "not maintaining history" is absolutely a critical fail at that org. Every decent tracking system I can think of has ways to import issues from other systems - skipping that step is pretty inexcusable for all but the earliest stage projects. And the vast majority of them have ways to transparently map ticket IDs. E.g. in Jira if you migrate a project and give it a new project ID, the old IDs can still be used and they will transparently redirect to the new ID.

heads 3y ago
Colour me old fashioned, but these tickets are usually web documents that can be located by a URL. It’s ok to use URLs for links! They are too long to fit into a title but fit nicely into the body text… See https://bugs.com/8765309 …with the advantage that many tools already know how to make these magic strings into clickable links. No need to rely on parsing #<id> or !<id> or whatever.
- mjcarden 3y ago
  You won't be able to call Jenny with a typo'd number like that.
- grogenaut 3y ago
  having worked at several places for a while, you end up changing the tracking system url over time. This has happened to me at the job I worked at for 8 years, the one for 3 years (actually more than the others), and the recent 10 year tenure. The first place was pre-jira popularity and we maintained our own system, or used systems from our clients. The second place was a game studio and had many more bugs than any other place I've worked. One game title we had, we had around 29k tickets, and cleared out 7k in our biggest week. The speed of the UI actually impacted the effectiveness of our throughput at one point. We started with Traq, then hansoft. But I think jira won out over hansoft due to the ability to customize it and then sony just maintaining a jira for us that their teams used to coordinate with us, so kinda a no brainer. The last one is interesting as Amazon has many tracking systems, and even if you use jira, over time the jiras were so crowded they had several, we used jira-4 (out of 7 or 8) before I setup one for our org. At twitch we've been consistent on our use of one jira instance since i've been there, but we've changed the url I think 4 times since during my tenure. In all of these places we've had many codebases that outlasted the urls. All of those places I've been we just use the short numbers like AND-3421. In the cases I needed to click them I could just use alfred or a tampermonkey script. It's a lot shorter as well.
  - sghill 3y ago
    The old URLs aren’t kept around to redirect to the new location?
    - danmur 3y ago
      My work isn't what I would call highly professional in terms of infra, but for us the old URL from our Jira move is dead and gone (including the parent domain) but the ticket references work in the new instance (redirecting to a new project name also). I think you just have to pick your poison, nothing's going to work all the time without small amounts of effort from IT.
      - sghill 3y ago
        Definitely - we recently moved issue tracking to another system after 15+ years and found there were too many links to abandon, so we run a service that just redirects old URLs.
kelnos 3y ago
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.
- physPop 3y ago
  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?
- 3y ago
pletnes 3y ago
I’ve never seen a ticket system migration keep links alive. I’m sure there are professional IT centric orgs out there that prioritize this, but in my experience, the version history (master branch) is what’s kept in practice, to keep migration cost down. Git blame is the best you can hope for, long-term.
brian_cunnie 3y ago
> 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.
- Nullabillity 3y ago
  Or... fix your permissions issue.
- hn_throwaway_99 3y ago
  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.

heads 3y ago

Colour me old fashioned, but these tickets are usually web documents that can be located by a URL. It’s ok to use URLs for links! They are too long to fit into a title but fit nicely into the body text… See https://bugs.com/8765309 …with the advantage that many tools already know how to make these magic strings into clickable links. No need to rely on parsing #<id> or !<id> or whatever.

mjcarden 3y ago
You won't be able to call Jenny with a typo'd number like that.
grogenaut 3y ago
having worked at several places for a while, you end up changing the tracking system url over time. This has happened to me at the job I worked at for 8 years, the one for 3 years (actually more than the others), and the recent 10 year tenure. The first place was pre-jira popularity and we maintained our own system, or used systems from our clients. The second place was a game studio and had many more bugs than any other place I've worked. One game title we had, we had around 29k tickets, and cleared out 7k in our biggest week. The speed of the UI actually impacted the effectiveness of our throughput at one point. We started with Traq, then hansoft. But I think jira won out over hansoft due to the ability to customize it and then sony just maintaining a jira for us that their teams used to coordinate with us, so kinda a no brainer. The last one is interesting as Amazon has many tracking systems, and even if you use jira, over time the jiras were so crowded they had several, we used jira-4 (out of 7 or 8) before I setup one for our org. At twitch we've been consistent on our use of one jira instance since i've been there, but we've changed the url I think 4 times since during my tenure. In all of these places we've had many codebases that outlasted the urls. All of those places I've been we just use the short numbers like AND-3421. In the cases I needed to click them I could just use alfred or a tampermonkey script. It's a lot shorter as well.
- sghill 3y ago
  The old URLs aren’t kept around to redirect to the new location?
  - danmur 3y ago
    My work isn't what I would call highly professional in terms of infra, but for us the old URL from our Jira move is dead and gone (including the parent domain) but the ticket references work in the new instance (redirecting to a new project name also). I think you just have to pick your poison, nothing's going to work all the time without small amounts of effort from IT.
    - sghill 3y ago
      Definitely - we recently moved issue tracking to another system after 15+ years and found there were too many links to abandon, so we run a service that just redirects old URLs.

kelnos 3y ago

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.

physPop 3y ago
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?
3y ago

pletnes 3y ago

I’ve never seen a ticket system migration keep links alive. I’m sure there are professional IT centric orgs out there that prioritize this, but in my experience, the version history (master branch) is what’s kept in practice, to keep migration cost down. Git blame is the best you can hope for, long-term.

brian_cunnie 3y ago

> 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.

Nullabillity 3y ago
Or... fix your permissions issue.
hn_throwaway_99 3y ago
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.