[alderz]

I love essays in commit messages! They can be very useful, especially when they describe why the change is being applied, instead of what is being done, which is usually the case.

Many high-profile projects have essays in their commits; I'm familiar with those of Go, e.g. https://github.com/golang/go/commit/5779bb4e92911271583faa13... (picked one at random).

[sadfklsjlkjwt]

Both are best! A brief concise first line summary together with a full message.

[aarong11]

I like to go with a brief "what i've done and why". Maybe "BUG-123 (Broken profile page) - Fixed missing CSS".

[xorcist]

Why did the bug happen? How were users affected?

Why was this particular "fix" chosen, instead of perhaps a more obvious alternative? (If I can choose only one thing to improve, it'd be this one! Had I gotten a penny for every head scratching "fix" that seems unnecessarily complicated or not a fix at all...)

What steps have been taken to avoid this in the future? New validations? Have new exceptions been introduced? New log rules? New monitoring rules? And if not, then why not?

Are these corresponding changes in other repos or this one? Is this change part of a larger series of changes?

There's so much more you'd like to know when you stumble on a commit like "fix missing css". Yes, some of this info is probably in the ticket. Yes, there is probably a discussion in the pull request. But likely not, if we are to be honest about it. And if it is, then all the easier to summarize in the commit message.

I'm one of those persons that read more code than I write nowadays, git log -G is my favorite command, and commit messages like the above hurts me daily.

[simias]

I've already made a similar comment elsewhere in this discussion but I really don't get why most of these things is better stored in a commit message than, say, as a comment in the code itself, which will always be here even if I'm just browsing through the code by following a call stack or if the file gets copied into another project for instance.

I don't "git blame" all the code I read all the time, and even if I did one small refactor or variable renaming is enough to make it tricky to track the original change back. Comments are forever.

[xorcist]

Comments and commit messages are complementary. The commit message describes the changeset and includes things like the above, the whys and the necessary context to understand the change. The comment describes the actual code as it is, and should describe how it works and how it interfaces with other code. Comments tend to be, as you say, forever while the code changes.

Both are well worth the time to write. Nicely written ones might even take a full minute or two to write, but how many cleaned-up and rebased commits does one produce in a day? A few, at most, unless they are absolutely trivial. Those minutes per workday are well spent.

[masklinn]

> I'm one of those persons that read more code than I write nowadays, git log -G is my favorite command, and commit messages like the above hurts me daily.

-G just looks for changes in the patch so the commit message would not be relevant save possibly once you've reached an interesting-looking revision, do you mean `--grep`?