When developers commit source code to a shared repository (for integration in software people like us use), they have the often-squandered opportunity to summarize the changes they are submitting. Linus (rightfully) thinks this opportunity should be leveraged more appr9opriately and more often, with more quality.

[–] leftytighty@slrpnk.net 5 points 1 month ago

Worth noting that this is stored in the repository alongside the code changes and can be referenced in the future if someone is trying to understand that code or fix a bug in that code.

For large projects spanning long periods of time sometimes the best way to find a bug's cause is to scour the projects history to find out which commit caused the bug to appear, and if that commit doesn't have a good description you're unnecessarily disadvantaged when trying to find out why it caused the problem or what assumptions were going into the original code.

[–] Crackhappy@lemmy.world 3 points 1 month ago (1 children)

Trying to figure out if that typo was intent9ional or not.

[–] plz1@lemmy.world 2 points 1 month ago

Nope I'm just awful.

[–] XTL@sopuli.xyz 2 points 1 month ago

If you're smart, you'll make good commit messages in any commit, no matter how small and personal the repo. Because one day you'll have no idea what that change was about and why and a small note will make it much easier to figure out.

[–] funkless_eck@sh.itjust.works 7 points 1 month ago* (last edited 1 month ago) (1 children)

You change some code and send it in, you add a cover letter explaining what you did and why. The Linux guy wants you to write more detailed cover letters when you do.

edit: wrote this before reading the article. he actually just wants people to write using active voice instead of passive.

[–] Brahvim@lemmy.kde.social 1 points 1 month ago

Aww, more personalized COMMITMSGs?!...

That's wholesome.