Re:Julia Evans: Git rebase, what can go wrong
by Izkata on Monday November 06, 2023 @07:04PM
(#38171155)
On a long-lived codebase you're going to end up with nearly as many such comments as there are lines of code. Now that's a cluttered mess.
[ Parent
| on HN ]
Re:Julia Evans: Git rebase, what can go wrong
by mixmastamyk on Monday November 06, 2023 @09:22PM
(#38172387)
When/how to comment is an art in itself, in no conflict to what I wrote.
Re:Julia Evans: Git rebase, what can go wrong
by Terr_ on Tuesday November 07, 2023 @01:04AM
(#38173741)
While it's often said that comments should capture the "why" of code, I don't usually think that ought to extend to "cuz ticket#" except when that ticket number is an significant bug/limitation that explains a nasty hack.
Noting each feature ticket that ever affected a line--or even just at the function level--is sort of like maintaining a few thousand incomplete micro-changelogs. Doing it "acceptably well" takes much more effort than grooming the commit history so that someone can click "show change history for selected lines" in their IDE.
Plus consider all the unnecessary noise it makes for people reading the code, or reviewing a PR.
Re:Julia Evans: Git rebase, what can go wrong
by mixmastamyk on Tuesday November 07, 2023 @06:28PM
(#38184585)
No, it's not difficult (cut/paste), nor a burden for reading in comments or docstrings. Could be measured in seconds instead of hours massaging history.
Also, you seem to be under the misconception history doesn't exist because it wasn't massaged, which is false.
Re:Julia Evans: Git rebase, what can go wrong
by Izkata on Tuesday November 07, 2023 @08:25PM
(#38185570)
And the commit message is an amazing place to put that.
Re:Julia Evans: Git rebase, what can go wrong
by mixmastamyk on Wednesday November 08, 2023 @05:15PM
(#38197914)
Not if you want them read by non-developers.