171–180 of 246 posts
I don't know about Linux Kernel, but in 99% of projects, 99% of commit messages are write-only.
Earlier quoted context omitted.
I look at commit messages quite often working on a 10+ year old code base. Bisect leads to the commit, the commit message explains why the change was made. I take the explanation from 10+ years ago and determine if the reason still applies today. Or, I bisect and there's a low quality commit from 10 years ago from a person long since departed that simply says "fixup" and I'm dead in the water.
Yup, way too many times I’ve encountered code that’s written in a peculiar way obviously for a reason, most likely to work around some issue, but it’s not clear what the issue is and whether it is otherwise resolved so that the peculiar code can be dropped. I bisect and it says “fix bug”, now I need to carry that crap forever or worry about reintroducing some unknown bug. (In case someone points out a comment is more…
Earlier quoted context omitted.
This is the typical trade off of management. You surrender low level control for higher level control and the ability to get more done overall (since you’re coordinating the labor of dozens of people).
But honestly, what Linus is doing strikes me as a much lower level than what we normally think of as the "management tradeoff". I mean, he's reviewing a ton of PRs, actually writing code in is email client as suggestions to patches. I see that as more of a "principal engineer" type role than an "engineering management" role.
> commit messages to me are almost as important as the code change itself This is high on my list of code craftsmanship points. It's very difficult to explain to young programmers who have never worked on an old code base how valuable this is when done well. In fact, often you hear complaints about how a code base "is crap", but more often than not I'd wager this is just a result of the context at the time not being…
I seem to be the only one in my team doing this, though.
(Obviously I also include a short but meaningful description of the change in the commit message itself. Again, not something everybody always does.)
> commit messages to me are almost as important as the code change itself This is high on my list of code craftsmanship points. It's very difficult to explain to young programmers who have never worked on an old code base how valuable this is when done well. In fact, often you hear complaints about how a code base "is crap", but more often than not I'd wager this is just a result of the context at the time not being…
(Now if I could just get them to squash, rebase and rewrite commit messages before publishing...)
Earlier quoted context omitted.
I like to remind people that pull requests are an abstraction over a set of commits. I show people that they can click on each individual commit in a PR and see the granular delta. Surprisingly often I’ve learned that people really don't know you can do this! If they argue that you cant revert entire features remind them that merge commits are a thing. If they don't like lots of merge commits littering the history su…
> If your team insists on 1 PR == 1 commit Yeah that's the scenario I'm thinking about. The trouble I have with this is two things: - People inherently don't make the PRs as granular as a commit would be, because it puts load on other processes (like CI, review overhead, etc.) and slows things down that way. So you end up with PRs that are hundreds of lines instead of self-contained commits that are dozens of lines l…
Earlier quoted context omitted.
I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…
All the "code quality" people write shitty systems. You are too zoomed in if you think code quality is really important. It's kind of important, but your system likely has much more important things wrong with it than the "code quality". Things you could actually get fired for, or seriously reprimanded if the winds don't blow in your favor. Almost all "code quality" discussion in PRs is lightweight value judgements w…
Good example from a couple days ago: someone made a helper method for compressing something, with the signature
string Compress(string value)
Other times it'll be something like a constant 30s timeout hard-coded, and I like that to have comments like:
// This usually takes // 30s is max or (calling code) times out anyway
Earlier quoted context omitted.
> If your team insists on 1 PR == 1 commit Yeah that's the scenario I'm thinking about. The trouble I have with this is two things: - People inherently don't make the PRs as granular as a commit would be, because it puts load on other processes (like CI, review overhead, etc.) and slows things down that way. So you end up with PRs that are hundreds of lines instead of self-contained commits that are dozens of lines l…
It’s less common but there are actually CI setups that verify each commit in a PR rather than the tip of the branch.
Earlier quoted context omitted.
I write detailed commit messages for every single commit I make(even though commits would be squashed on merges), I write detailed PR descriptions that included before/after screenshots in multiple resolutions whenever relevant. Never once did I have any indication that someone took their time to read descriptions or commit messages. In my previous job, I received some feedback from my manager that some people compla…
All the "code quality" people write shitty systems. You are too zoomed in if you think code quality is really important. It's kind of important, but your system likely has much more important things wrong with it than the "code quality". Things you could actually get fired for, or seriously reprimanded if the winds don't blow in your favor. Almost all "code quality" discussion in PRs is lightweight value judgements w…
Style is in my opinion very arbitrary. It's good to be consistent, and for that reason I guess it's good to have rules that are enforced, but with the number of times I have to revisit my changes because apparently I'm violating some obscure style rule, and therefore the build server rejects my change (or sometimes it even rejects it because someone else's change violated something, which makes me wonder how that ever got through), it feels like it's a waste of time to be too strict about it. A bit of personal style isn't going to kill anyone.
Earlier quoted context omitted.
I look at commit messages quite often working on a 10+ year old code base. Bisect leads to the commit, the commit message explains why the change was made. I take the explanation from 10+ years ago and determine if the reason still applies today. Or, I bisect and there's a low quality commit from 10 years ago from a person long since departed that simply says "fixup" and I'm dead in the water.
Commit messages are supposed to be short. "Fixed stuff" is totally wrong. I usually write "Added ability to do foo with bar when baz is true." Commit messages aren't mutually exclusive to the inline documentation. I am making the case that inline documentation is far more important than commit messages.
Commit messages are about the change, whereas comments are about the state of the code.