3 ms·

Curious, I've run into this approach in the past and learned to hate it with passion. That place used JIRA where the typical ticket ID was around 10 characters

Curious, I've run into this approach in the past and learned to hate it with passion. That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate, e.g. in my email inbox, in history views (tig, gitk, and so on). I also don't see the claimed benefit for git blame. In a real code base with significant history, it happens often enough that the first blame is an unrelated refactoring and you need to dig deeper. Therefore, I find that best practice is to look at the blamed commit first instead of the ticket. That gives you the full commit message, which can still contain a reference to an issue. Putting footer lines like "Fixes: <issue>" into commit messages works much better. It's just as easily visible in git log etc. and doesn't waste space.

kgeist 5y ago
I view the commit message first, of course, and only if it's not enough, I go to the issue tracker. >That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate Interesting, just for the sake of it, I measured how much screen space the issue ID takes up on my monitor with my current font settings - around 5% (of monitor width, of course). Never been a problem for me.
- atq2119 5y ago
  If you view the commit message first, then I don't see how having the issue ID as the first thing helps your git blame use case. You can see the issue ID just as easily in a footer line of the commit message. As for screen space, one of the standard email client layouts has a vertical split, with message titles on the left and bodies on the right. This generally fits well with 16:9 screens, but the line width for titles is limited. Having e.g. the affected component or subsystem up front is much more useful when skimming.
  - kgeist 5y ago
    As long as the issue ID is somewhere in the message, I'm fine with it :) But, for example, yesterday I was cherrypicking many small commits pushed by a junior dev to wrong branches and it greatly helped that it comes first, there's less mental burden, it's easier to spot. We also have a tool which checks issue IDs in commit messages against the issue tracker (various custom states in our flow) and, again, it's more robust and simpler to implement if there's a standardized place where to put your issue ID.

kgeist 5y ago

I view the commit message first, of course, and only if it's not enough, I go to the issue tracker. >That place used JIRA where the typical ticket ID was around 10 characters. That wasted a lot of prime real estate Interesting, just for the sake of it, I measured how much screen space the issue ID takes up on my monitor with my current font settings - around 5% (of monitor width, of course). Never been a problem for me.

atq2119 5y ago
If you view the commit message first, then I don't see how having the issue ID as the first thing helps your git blame use case. You can see the issue ID just as easily in a footer line of the commit message. As for screen space, one of the standard email client layouts has a vertical split, with message titles on the left and bodies on the right. This generally fits well with 16:9 screens, but the line width for titles is limited. Having e.g. the affected component or subsystem up front is much more useful when skimming.
- kgeist 5y ago
  As long as the issue ID is somewhere in the message, I'm fine with it :) But, for example, yesterday I was cherrypicking many small commits pushed by a junior dev to wrong branches and it greatly helped that it comes first, there's less mental burden, it's easier to spot. We also have a tool which checks issue IDs in commit messages against the issue tracker (various custom states in our flow) and, again, it's more robust and simpler to implement if there's a standardized place where to put your issue ID.