Hacker News new | ask | show | jobs
by ralferoo 8 days ago
Personal preference I guess, but to me all of those commit messages are way too wordy. I'd probably have:

  [PRJ-123] Refactor Foo out from Bar

  [PRJ-123] Include Foo data in BazClient

  [PRJ-456] Null-guard on Foo ID to avoid data loss
  Bug introduced in commit deadbeef
And then in PRJ-456, I'd also have the comment about bug introduced in commit deadbeef, and link the two JIRAs if it was significant, or just mention it in a comment for a minor fix.

For me personally, nothing else in your commit messages adds value that can't be seen trivially from glancing at the changes.
1 comments
andrybak 8 days ago
Git is more robust than Jira. Git log is accessible offline. Jira descriptions exist only as long as people managing the Jira instance are competent and are migrating the necessary data correctly when migrations are needed. Even migrations from one Jira instance to another (e.g. when companies get acquired and two Jira servers get merged) can be extremely brittle.

It's fair that maybe such simple trivial changes don't deserve such a wordy commit message. But these are just fictional examples that I came up with on the spot. Refactorings, new features, and bugfixes can all have various levels of complexity.

A good commit message helps answer the "why?" questions first and foremost. If a diff is fairly large, pointing out the most important change can be useful. Explanations for non-trivial dataflow can sometimes not make sense in separate documentation, but still be relevant in a commit message.

link
dinfinity 8 days ago
> Git is more robust than Jira.

Much of such issue tracking systems may be better in the repo in the first place. A Jira issue could just be a markdown file committed in the repo. A code review could just be commits of inline remarks/comments.

Maybe there is some value to slapping on a web interface on top of that data for ease of use, but as to where the data lives I'm leaning towards putting everything in repo.

link