3 ms·
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 aroun
by 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 agoIf 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 agoAs 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.