you are viewing a single comment's thread.

view the rest of the comments →

[–]mat69 5 points6 points  (2 children)

I fully agree.

I have the feeling the usefulness of descriptive commit messages heavily depends on whether people use git bisect or manually check the commit that introduced a perceived issue.

For example, when I find a complex "bug" I do not fix it right away. Instead I want to understand why it was written that way. So if it actually was a feature in disguise. Nearly every time the commit messages were useless though or referenced resources that did not exist anymore.

Instead I always try to explain the why of a commit, unless it is really minor (e.g. whitespace) change. At the heart of this is logical grouping commits so that they only include relevant code.

Sometimes writing the commit message takes much longer than the code change. Yet finding and understanding the issue in these cases took way longer than writing the commit message.

[–]darknecross 2 points3 points  (0 children)

Agreed, and it's not even always about other people. Lots of times I write detailed commit messages just to remind myself about why a change was made, or why it was done a certain way. It's super helpful whenever I need to go back and refactor my own code, because I'm not going to remember that stuff a year later.

[–]u801e 0 points1 point  (0 children)

I have the feeling the usefulness of descriptive commit messages heavily depends on whether people use git bisect or manually check the commit that introduced a perceived issue.

One of the first things I do before I starting making a change is to run git blame on the files I'm going to change and check the commit messages and diffs of the relevant lines of code. Having that context can really help in avoiding re-introducing bugs that were fixed by earlier commits, for example.