My Favourite Git Commit

> Why doesn't it? Are closed issues not searchable?

Everywhere I have ever worked has changed ticket systems at one point, and even when they are transferred, the transfer is "lossy".

Heck, just moving from one JIRA version to another can be "lossy".

> How do you provide comments or updates on an issue "relevant to the commit" without arbitrary commits?

In the ticket system. I was not advocating that a ticket system is pointless, because they are very useful.

But a decent commit message about why a change is necessary, especially when it may not be straight forward, can save you plenty of development time further down the line.

They definitely belong in comments though. Names, non-English languages and the like.

Contrary to the author's point, I don't think a git commit becomes more beneficial to the readers by adding a human context.

Building "compassion and trust" actually distracts readers from the essence of the commit: what happened and why. I am not discarding the importance of human element in collaborative endeavors but maybe such area should be pursued outside of a version control system.

When reading code, you want somthing simple and to the point most of the time (if that). Yes, it's nice to be able to tunnel down into the details - but this was fixing a bug, the code should just have a short description and more so - the reference number of the bug and if you need to, you can look that up on your bug tracking solution and get that detail.

Big problem with detailed comments, things change and comments (like code) can become obsolete/redundant and not reflect the code as the code got updated, but the ocmment did not.

No solid solution really and gets down to preference and also mindfulness of the life of code/comments.

Would be great to have code that you could rightclick and get the documentation, some woudl even prefer being able to write documentation and that gets turned into code, others would love code that could could be autodocumented. Get's down to taste, preferences and more so, experience. See, every programmer over time will eventually encounter a situation on somebody else's code that they are maintaining, fixing or replacing and find that the comments do not reflect the code. You eventually get down to the stage that you almost actively ignore comments based upon such experiences.

So whilst a detailed description in the form of a comment is good, it can and should be elsewhere, either the initial spec and program documentation or in this instance - bug tracking software system and just simple short line with bug reference or indeed just bug reference.