5 ms·

We also have a rule to prepend every commit message with its issue number in our issue tracker (we don't use GitHub). That way in Git Blame/Log you can always q

by kgeist 5y ago

We also have a rule to prepend every commit message with its issue number in our issue tracker (we don't use GitHub). That way in Git Blame/Log you can always quickly find where the change came from and why - the issue tracker usually has more detailed information.

hansoolo 5y ago
Yup, we do the same and it works out pretty well this way.
toastal 5y ago
This really treads on the char limit in the titles though
selcuka 5y ago
We do the same and it works pretty well. The problem with that approach, though, the codebase may live for decades but issue trackers change and old tickets usually don't get migrated to the new system.
- kgeist 5y ago
  >old tickets usually don't get migrated to the new system Well, our current issue tracker was migrated from Jira and I can still see all the ancient Jira tickets just fine (I mean what's important: the comments). In any case, something is better than nothing at all.
atq2119 5y ago
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.

by kgeist 5y ago

hansoolo 5y ago

Yup, we do the same and it works out pretty well this way.

toastal 5y ago

This really treads on the char limit in the titles though

selcuka 5y ago

We do the same and it works pretty well. The problem with that approach, though, the codebase may live for decades but issue trackers change and old tickets usually don't get migrated to the new system.

kgeist 5y ago
>old tickets usually don't get migrated to the new system Well, our current issue tracker was migrated from Jira and I can still see all the ancient Jira tickets just fine (I mean what's important: the comments). In any case, something is better than nothing at all.

atq2119 5y ago

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.