> " in the end, my job is to say no. Somebody has to be able to say no to people. " This is funny to me, because I feel like Linux got ahead over BSD specifically because it had a more accepting policy in the beginning. I think this says something important about project maturity and lifecycle. BSD was already a "well established" system by the time the Linux kernel appeared, and as such had more gatekeeping to meet…
There was also the licensing/copyright controversy. It wasn't clear that BSD was really free until Linux was already taking off. From 1992-1994 there was a legal cloud over BSD and probably even after that people had lingering doubts that something like that could happen again. https://en.m.wikipedia.org/wiki/UNIX_System_Laboratories,_In... .
Linus Torvalds: 'I Do No Coding Any More'
151–160 of 246 posts
Re: Linus Torvalds: 'I Do No Coding Any More'
#152> 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…
Head of Engineering with 15 years of experience here. If found that when we starting using Github flow, with pull-requests and etc, commit messages stopped really matter, in favour of PR descriptions. Plus when you use "squash" strategy, and use PR description as commit message, history looks great. When you look at commit history through Github tooling, all PR ids turned into links, and it is very easy watch for the…
Re: Linus Torvalds: 'I Do No Coding Any More'
#153Earlier quoted context omitted.
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.
There's no general rule about what length a commit message should be, except that often people try to keep the first paragraph as a single short line for better readability in systems like GitHub and the git CLI. When additional detail is helpful about the motivation for or gotchas related to a commit, starting a new paragraph and elaborating there is totally fine. But I agree with you, they aren't mutually exclusive…
This also follows what I've seen at a few companies since then. Would you say that's a general rule?
Re: Linus Torvalds: 'I Do No Coding Any More'
#154Earlier quoted context omitted.
Another thing those juniors are seldom good at, is knowing how to refactor an existing old code base. Which is not surprising, as everything they worked on during education is new code. Knowing how to change a code base from one abstraction to another is a skill that often take many years and lots of mistakes to learn.
Yet another boomer generalization designed to sow biases against hiring younger people. At what age am I allowed to become a senior, oh wise one?
Re: Linus Torvalds: 'I Do No Coding Any More'
#155> 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 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…
Almost all "code quality" discussion in PRs is lightweight value judgements with no rigor or consistency. Just what random bikeshedding objection that person happened to think of, maybe they had a bad night's sleep? Who knows...
Remnants of an era where most software was low stakes and had low number of users. We now have many more "-ilities" we are judged on, that are measurable and that actually matter, so ignore the code quality trolls stuck in 2005.
Re: Linus Torvalds: 'I Do No Coding Any More'
#156Earlier quoted context omitted.
I've seen that useful commit message make it incredibly easy to see where the code came from and is going. It also never gets 'out of sync' like code comments tend to, as it's a comment on a static place in the code, not a dynamic one.
> It also never gets 'out of sync' like code comments tend to, as it's a comment on a static place in the code, not a dynamic one. That's simply not true, not in a git world where rebasing to rewrite history is standard practice.
Re: Linus Torvalds: 'I Do No Coding Any More'
#157Earlier quoted context omitted.
I consider the version control history to be part of the code. I put docs into the source tree (sometimes in the form of comments; sometimes in dedicated doc files) for things that are suited to live next to the code, but often my commit messages contain more discussion of what used to be and why I chose a certain implementation approach. I generally think that documentation in code should describe what the code does…
Code tends to live longer than the VCS that stores it. I've seen more than one VCS migration that ended up losing a lot of the history of how things got to be where they are today.
With care, it's possible even to merge different git repos into a single repo while preserving history. But it takes care; it's not a pit of success.
Re: Linus Torvalds: 'I Do No Coding Any More'
#158Earlier quoted context omitted.
How do you convince other people of this though? That's been what I've struggled with. I hate squashing too, but I can't convince anybody.
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…
Rebase and push -- along with some squashing of redundant work-- is great. There's some degree of annoyance if intermediate states don't build, so it requires care to know that all the individual between states are probably safe (because CI, etc, generally don't help you here).
Merge commits are fine, though they do require a higher degree of acumen for people exploring the history.
And there's plenty of times when a developer submits a moderate sized 3 commit PR that whoever looks at the pull can decide that it's better to squash and make into one commit.
Re: Linus Torvalds: 'I Do No Coding Any More'
#159> 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…
for bob's old ERP software company, really won't make a difference
Re: Linus Torvalds: 'I Do No Coding Any More'
#160My guess is Linus is still L&M (if people didn't enjoy his lean, they wouldn't appreciate his mean), but perhaps he's not in his element right now (and just taking a breather).
Either way, I'm a fan (not a professional) of a lean (looking) codebase with perhaps a new "overlay" commenting system being developed to accommodate a wide range of proficiency (one size fits all is either too terse or too bloated).
I am not sure of the difficulty of linking comments by line number between revisions, but outside of having an official repository of comments, being able to toggle through multiple perspectives from the same line/set of code would offer valuable insight and chronicle mindset/POV in a way that a global scratchpad could never deliver.
Writing terse or bloated comments should not be top of mind, but rather a frictionless byproduct (expect terse, but be pleasantly surprised on occasion by the detail and multiple perspectives).