scottgonzalez
commented
10 years ago This can be extended to track more than just a single commit for a fix. It could track partial fixes, general references, regressions, etc.
Open scottgonzalez opened 10 years ago
scottgonzalez
commented
10 years ago This can be extended to track more than just a single commit for a fix. It could track partial fixes, general references, regressions, etc.
rxaviers
commented
10 years ago :+1:
It's common for bug trackers to create comments that link to the commit that fixes a bug (#4), but this could be expanded to provide much more value. If the commit is actually tracked in a structured way, you can create more meaningful queries. For example, if there are users who just pull the latest code every once in a while instead of only using official releases, they would be able to query all tickets closed since the specific commit they're currently using.
If the commit metadata is tracked as well, you can capture additional data such as the actual time of the fix. For tickets that are closed by a commit with a reference (causing the ticket to auto-close), then the time the ticket is closed represents the time the ticket was fixed. However, there are two common scenarios where the times don't match up. 1) The ticket was fixed but the dev didn't know about the ticket or forgot to reference the ticket in the commit. 2) The bug is reported after the bug is fixed, but before a new version is released (or before the user who encountered the bug has upgraded). Being able to query against close time or fix time would be interesting.
This would require the ability to manually link the commit to the ticket for the aforementioned cases.