Hacker News Reader

Comment by pilif | Hacker News Reader

also great commit message: https://github.com/spacejam/sled/commit/b7a5d14399540daa433a...

the limit to 16 threads under windows was added in a commit named "refactor imports".

If somebody in the future tries to find out why the threads are limited to 16 under windows, they will eventually end up at that commit and if the committer isn't around any more (or doesn't remember), nobody will ever know the reasoning.

For projects that have even the slightest chance of staying around, be mindful about your commit messages and explain why you are doing something, not what you are doing - that's what the code itself is for.

View on HN

I would also argue for a short comment in the code for things like this. Code gets shared and the version control doesn’t always come with it. I’m mostly bitten by this when using some vendor’s SDK where they release a tarball of the code but keep the repo private. But even within your own organization, code will get copy/pasted to another repo and the comment is more likely to go with it.

> be mindful about your commit messages and explain why you are doing something, not what you are doing

It's sad to see how many experienced programmers do not understand this. Of course, it takes a little more effort, but without this type of thinking you might as well skip the commit message completely. I am a very junior programmer and it was one of the first thing I was corrected for not doing, and rightly so.

Code for your future self in 6 months time...

spacejam (Author) comments:

for the hn h8rz: you don't deserve performance bwahahhahaha maybe this should actually be dropped to 0 olololololololol

https://github.com/spacejam/sled/commit/b7a5d14399540daa433a...

I've seen this kind of thing many times before: the developer wants to commit something (in this case, an import refactor), and accidentally commits other changes which were being worked on. This is why I don't recommend getting into the habit of using "git commit -a".

absolutely. I'm telling people to always use `git add -p` to help them produce self-contained commits.

And if you screw something up, there's always `git commit --amend` or the sledgehammer of `git rebase -i`.

Note: I'm not advocating doing this to public history, but I'm saying: Use these tools in order to create self-contained changes on your end before committing them to public history.

When I'm doing archeology trying to find out why Foo is doing Bar instead of Baz, I don't want to know that back then, 10 years ago, you fixed a typo or added a "forgotten file".

Reply on news.ycombinator.com