Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds: 'I Do No Coding Any More'

linux.slashdot.org

Post reply on HN
Print view View original

161–170 of 246 posts

Re: Linus Torvalds: 'I Do No Coding Any More'

#161

Post by nemetroid »

aaomidi wrote: post #141
dasil003 wrote: post #26

> 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…

Until you use squash and merge. Suddenly commit messages become far less helpful.

Yep, a good argument against squash and merge.

Re: Linus Torvalds: 'I Do No Coding Any More'

#162

Post by MaxBarraclough »

cwsx wrote: post #153
jkaplowitz wrote: post #127

Earlier quoted context omitted.

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…

I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follows what I've seen at a few companies since then. Would you say that's a general rule?

There's now an effort to (loosely) standardise this convention: https://www.conventionalcommits.org/en/v1.0.0/#summary

Re: Linus Torvalds: 'I Do No Coding Any More'

#163

Post by rowanG077 »

vp8989 wrote: post #155
mrisoli wrote: post #92

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…

It seems to me you are confusing code quality with style. Code quality is most certainly important. Style less so even though it should be consistent. Almost all bike shedding comments are style.

Re: Linus Torvalds: 'I Do No Coding Any More'

#164

Post by xorcist »

systemvoltage wrote: post #111
0xEFF wrote: post #109

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.

"Supposed" to?

Git was made with the intention that commit messages look like whole emails, describing not only why the change was made but also the thought process behind it, why this particular solution was chosen instead of some other etc.

What you describe is a decent header, although most people would probably prefer "Add ability to" (not "Added ability to", this is a custom that goes way back before git).

Inline documentation, or comments, is something else entirely. That is a moving target that can describe intended usage, remote APIs, and hard to understand passages. Commit messages describes a particular changeset, at a fixed point in time.

Google it, and see that most people's ideas of a good commit message goes way beyond the header ("shortlog") line.

Re: Linus Torvalds: 'I Do No Coding Any More'

#165

Post by djKianoosh »

dasil003 wrote: post #26

> 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 think the inexperienced developer simply hasn't had to personally dig through old commits/history to solve enough problems.

There's likely a threshold (a 10000 hours type thing) where you've researched enough code history to value great commit messages and descriptions and docs/readmes, issue descriptions and comments etc.

But how do we impart the importance of this to the other devs around us that will make it stick? Past "war" stories?

Re: Linus Torvalds: 'I Do No Coding Any More'

#166

Post by xorcist »

jacquesm wrote: post #130
pcl wrote: post #117

Earlier 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.

Look at all the long lived open source software around, be it Linux itself, gcc or KDE. They all have gone to great lengths to preserve all commit history across all migrations of VCS or code hosting.

(Sometimes absurdly so, as in the case of gcc, where flamewars have been fought to preserve commits that were broken to begin with.)

That is important, and that much care for the code probably helped them survive for so long. Botched VCS migrations is not something that should be accepted anywhere.

Re: Linus Torvalds: 'I Do No Coding Any More'

#167

Post by jkaplowitz »

cwsx wrote: post #153
jkaplowitz wrote: post #127

Earlier quoted context omitted.

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…

I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follows what I've seen at a few companies since then. Would you say that's a general rule?

I've never seen that anywhere I've worked, though it's a readable enough format that it wouldn't bother me if someone decided to adopt it for a good reason like compatibility with parsing by dev workflow dashboards or other automatic tooling.

Though, I'm not sure it's a helpful restriction for commits that clarify, refactor, or clean up code. One can certainly reference an issue tracker number as the {feature/bug} element that gives the necessary context, but the strictness spreads the information around more widely than is natural.

If someone was adopting that convention as a workaround for helping team members learn how to communicate, they're probably going to find that it's a very incomplete workaround.

Re: Linus Torvalds: 'I Do No Coding Any More'

#168

Post by detaro »

jacquesm wrote: post #146
pcl wrote: post #144

Earlier quoted context omitted.

I guess I’m an optimist on that front. I’ve lost history from CVS and SCCS, but not from SVN, Perforce, Git or Mercurial, including a number of Git module extractions. I think that history-losing version control migrations are a thing of the past.

Check out a 'zip' file to cross port to a system that does not support your VCS of choice (many embedded systems, for instance) and poof half your docs are gone... VCS should store the code, commit messages should aid in bi-secting but should not explain too much other than to clearly document what was changed in that commit with reference to a particular ticket if available. That way you keep the meta stuff in one p…

Where do you encounter such embedded systems where you then do work on the code on said system?

In my niche of embedded work, the "host" machine stays the main interface to work with code almost always (and in the exceptions the "embedded" system is typically PC-grade hardware running Linux)

Re: Linus Torvalds: 'I Do No Coding Any More'

#169

Post by worik »

" 'No, this is fine, but...' And I send out pseudocode, or — I'm so used to sending out patches that I sometimes edit patches and send out the patch without having ever compiled it, ever tested it, because I literally wrote it in the mail reader, "

Yes he does so write code....

Re: Linus Torvalds: 'I Do No Coding Any More'

#170

Post by jkaplowitz »

MaxBarraclough wrote: post #162
cwsx wrote: post #153

Earlier quoted context omitted.

I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follows what I've seen at a few companies since then. Would you say that's a general rule?

There's now an effort to (loosely) standardise this convention: https://www.conventionalcommits.org/en/v1.0.0/#summary

Ah! That seems slightly different from the format the person you're replying to described, but I have seen this version in use at one job.

There was only used by one person who gave no context on why he used that format, so it's probably no coincidence in such an example that to me the extra structure seemed to add only opacity and no real value.

I can absolutely imagine that being different in a company that used this convention widely and built tooling around it. Doubly so when a lot of the staff is junior enough that it's helpful guidance for structuring thoughts around what the commit does.

Post reply on HN