Linus Torvalds: 'I Do No Coding Any More' • Hacker News Board

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

#201

Post by cwsx » Mon, Jul 06, 2020, 1:21 AM UTC

jkaplowitz wrote: post #167

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?

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

I should note this is normally done on a feature branch (with the ticket number attached). i.e. feature/{ticket-#}-{ticket-title}

When merging you can pretty easily see what ticket each commit was for. Seems superfluous to put the same information in every commit messages.

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

#202

Post by u801e » Mon, Jul 06, 2020, 1:31 AM UTC

mehrdadn wrote: post #178

dcow wrote: post #176

Earlier quoted context omitted.

It’s less common but there are actually CI setups that verify each commit in a PR rather than the tip of the branch.

That seems immensely more painful for a nontrivial project though. It'll clog the CI for everyone and nobody will go back and rebase to make sure every single commit is a self-contained passing unit.

It's trivially easy to do if you run something like:

  git rebase --exec "test_command"

where test_command is one or more commands that you run to test the code for that commit. I typically do this for unit tests and integration tests.

If the tests fail for some reason, you can amend the commit to fix the test and then run

  git rebase --continue

to test the next commit.

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

#203

Post by u801e » Mon, Jul 06, 2020, 1:36 AM UTC

aeontech wrote: post #190

mrkeen wrote: post #139

Earlier quoted context omitted.

I squash before I open the PR. Then I have last say in the commit message. Also it gives me a chance to figure out what I actually worked on.

I (and my team) always run an interactive rebase before opening PR. This gives us a chance to reorder, squash and cleanup individual “work in progress” commits into a logical set of atomic, meaningful commits, without turning the entire PR into a single commit.

On my team, we will open a PR with a logical set of commits. As reviews are posted, we will address those comments by using fixup! or squash! commits (using the title of the commit we want to amend). fixup commits are used for code changes and squash commits are used for commit message changes.

In the end before merging, we'll run

git fetch orgiin

git rebase -i --autosquash --keep-empty origin/master

git log -p --reverse origin/master..

git diff @{u}..

The first command will update the remote tracking branches. The second one will start the interactive rebase and order the commits based on the fixup! and squash! tags we used during the review. The third one will show the commit messages and associated diffs for the branch so that we can check that things make sense. The last one is to verify that we didn't inadvertently introduce a change during the rebase (though we will see a diff if someone else merged a PR into master before this rebase).

will verify that no diff was introduced during the rebase compared to the upstream branch as referenced by the PR.

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

#204

Post by phlakaton » Mon, Jul 06, 2020, 1:59 AM UTC

systemvoltage wrote: post #103

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…

Yep, no one ever reads them and the cost to benefit ratio is extremely low. Writing good comments is far more important. Don't explain what the code does - that's what the code is for, explain the why and the background information in the code. Additional, explain what the code does at the function level or at the module level - at a much higher abstraction level basically than the line of the code. No one ever looks…

I can't say I _read_ commit messages all the time. I do however, _look_ for commit messages all the time.

And am frequently disappointed.

The comments I put in commits are things you'd be horrified to see littering your codebase (though I did it that way once upon a time too). They are the "whys" behind a change. Sometimes they have relatively little to do with individual lines of code, and don't need to be maintained like comment blocks should be. The temporal binding is absolutely intended.

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

#205

Post by _bxg1 » Mon, Jul 06, 2020, 2:40 AM UTC

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…

As a relatively young developer, I have to ask, are comments not a better place to document context? Commit messages are much less discoverable to me than comments when I'm looking at a piece of code. I usually put the "why" in comments and the "abstracted what" in commits. Enough info for someone to quickly rule whether or not a commit could have introduced a given bug, since that's usually what I'm looking for when I'm going through commit history.

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

#206

Post by mdtusz » Mon, Jul 06, 2020, 3:14 AM UTC

aaomidi wrote: post #196

nemetroid wrote: post #161

Earlier quoted context omitted.

Yep, a good argument against squash and merge.

I guess it's an argument for and against it at the same time.

We had this argument recently at my workplace and dug into the pros and cons of both, ultimately settling or regular merges and no squash.

The only real argument for squash-merges is that history remains linear and visually "clean", but if you want to see a "clean" history of only the merge commits, you just can just use the `--merges` option on the command line.

Squash locally if you really want to or need to, but I'm a firm believer of disallowing it as the merge method for a changeset.

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

#207

Post by sys_64738 » Mon, Jul 06, 2020, 3:35 AM UTC

arp242 wrote: post #28

yjftsjthsd-h wrote: post #19

Earlier quoted context omitted.

How is that not what happened? Torvalds wrote code, and now he manages other people writing code. He's not a people-manager; he is at least still in a technical role, but he's not a dev anymore.

I assume he's in his current position by choice. He pretty much says so: "It is an interesting job". He still deals with plenty of code; he just doesn't write original code. Calling it a "managerial or administrative type role" as the previous comment did is somewhat lacking in nuance, IMO.

He's not a developer and hasn't been for a while. He's a TPM by sounds of it. Don't understand the downvotes but perhaps that's down to junior developers who don't understand what a TPM is.

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

#208

Post by alexchantavy » Mon, Jul 06, 2020, 4:20 AM UTC

xorcist wrote: post #164

systemvoltage wrote: post #111

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

"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). Inlin…

GitHub discourages making commit messages longer than a certain number of characters; it’s interesting for me to see other opinions on that.

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

#209

Post by andersonvom » Mon, Jul 06, 2020, 4:27 AM UTC

alexchantavy wrote: post #208

xorcist wrote: post #164

Earlier quoted context omitted.

"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). Inlin…

GitHub discourages making commit messages longer than a certain number of characters; it’s interesting for me to see other opinions on that.

You're talking about the title of the commit message. Yes, the title is supposed to be under 50 characters. Now add a blank line after it and you can write all you want (line wrap at 72 chars).

If you use markdown Syntax in your commit body, github and other tools will gladly render it correctly. You can grep for commit messages with "git log --grep " and it will also search commit bodies as well. It's beautiful!

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

#210

Post by alphachloride » Mon, Jul 06, 2020, 4:28 AM UTC

xorcist wrote: post #164

systemvoltage wrote: post #111

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

"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). Inlin…

Could be selection bias. People who comment about good commit messages are most likely people who pay attention to commit messages. That does not necessarily mean they make up a majority of committers.