4 ms·

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

by pilif 7y ago

also great commit message: https://github.com/spacejam/sled/commit/b7a5d14399540daa433a1c9352359e3664e41967 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.

hnarn 7y ago
> 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.
- andy_ppp 7y ago
  Code for your future self in 6 months time...
cesarb 7y ago
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".
- pilif 7y ago
  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".
oops 7y ago
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.
tomcatfish 7y ago
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/b7a5d14399540daa433a1c9352359e3664e41967#r37417176 https://github.com/spacejam/sled/commit/b7a5d14399540daa433a...

by pilif 7y ago

hnarn 7y ago

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

andy_ppp 7y ago
Code for your future self in 6 months time...

cesarb 7y ago

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

pilif 7y ago
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".

oops 7y ago

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.

tomcatfish 7y ago

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/b7a5d14399540daa433a1c9352359e3664e41967#r37417176 https://github.com/spacejam/sled/commit/b7a5d14399540daa433a...