5 ms·
No one reads git history any way. Instead of writing commit messages, better write code.
by cynicalsecurity 2y ago
No one reads git history any way. Instead of writing commit messages, better write code.
- chatmasta 2y agoIf you write good commit messages, you’ll read them when you come across them. Debugging a problematic commit is less painful when its commit message teleports you back in time to when it was written, and clearly expresses the intent of the change.
- erik_seaberg 2y agoI absolutely do rely on commit messages, and ask for good ones during code review. Everybody on call needs to know how to find root causes in "git log" at 3 AM. The source can't serve the same purpose; including the complete history of what changed when and by whom would make it unreadable (especially things that used to be there but aren't now).
- move-on-by 2y agoI do, but all I really need from the git is who, when, and a reference to a ticket. The code itself- combined with who wrote and when will generally tell me all I need to know. From there, a ticket will give me the any extra context might need.
- rcxdude 2y agoThat's just storing the information in a commit message in a separate database. Fine so long as you maintain the cross-links.
- funcDropShadow 2y agoBut ticket systems are less stable than commit messages. Some companies decide to migrate to a new ticket system without migrating all the old "unnecessary" stuff.
- okaleniuk 2y agoSomehow, in less than 2 decades, people forgot that there was life before git. Before commit messages became compulsory, we used to write comments right in the code. And that was fine.
- rcxdude 2y agoThey serve different purposes, and yeah, you can go without (either commit messages or comments, or even source code), but it just makes certain investigations more difficult, sometimes many times so.
- rcxdude 2y agoCounter-anecdata: I read git history extremely frequently, across a variety of projects. Useless commit messages suck.