4 ms·

You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was

You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.

mgkimsal 4y ago
and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people. Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.
- twhitmore 4y ago
  As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made. Also more than mildly useful for devs doing porting work. Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.
  - wizofaus 4y ago
    I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.

mgkimsal 4y ago

and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people. Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.

twhitmore 4y ago
As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made. Also more than mildly useful for devs doing porting work. Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.
- wizofaus 4y ago
  I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.