Hacker News new | ask | show | jobs
by danvet 5357 days ago
In the linux kernel community, you'd get shot for this attitude. Now granted there are not many projects out there with this scale and complexity, but still: A one-liner commit-message for anything else than a trivial refactor is stupid. You want motivation for that change, references to bug reports and analysis of the problem (and potentially other ways to solve it and why they were rejected) in there.

And you absolutely don't want all that crap in the source code, because it routinely happens that a few lines of diff require a few paragraphs of commit message to explain why this is the right thing to do.

And browsing that massive amount of information with recursive git blame (or gitk's equivalent) and the more specialized history digging functions is easy. At least much easier than browsing through the equivalent embedded in source files, and I've seen the latter.

One thing you're right, though: Writing concise one-line summaries of a commit (which is the only thing a git shortlog shows) is a must.

1 comments

The kernel folks shoot people regularly for far milder offenses, so that's not really surprising. That said, I don't think we're reading commit logs for the same kernel. I see two-liners routinely in the log (because checkpatch wants the shortlog and a body -- but note that these are often just rephrasings of each other). And the kernel workflow encourages batching up what would otherwise be many small changes into well-formed patch sets, which means that you get a coarser granulatiry of changes than many projects.

And sure, there are patches that go in with elaborate analysis in the commit log. Where those provide good information, I think they're great. Most of the time, they just amount to a BUG() trace stuffed in for no good reason and I find them to be noise.

And I don't see how git blame helps my problem. I have a regression, and an intuition of what kinds of changes might have caused it. A commit log will tell me whether a commit seems like a good candidate to inspect. Git blame just tells me who touched specific lines. If I knew the specific lines to look at, I wouldn't need to be applying intuition here, I'd just fix the bug.