3 ms·

It has been an obvious net time gain for my projects. I do a lot of system programming, and often there are very complex reasons why a particular function is ca

It has been an obvious net time gain for my projects. I do a lot of system programming, and often there are very complex reasons why a particular function is called in a non-obvious way, especially after tricky bugfixes. Having a somewhat detailed written record associated with the commit, that won't rot like an inline code comment would, has been very useful in my experience. And all my thoughts become instantly available to all the future code readers, who will most likely not be me.

ses1984 7y ago
>that won't rot like an inline code comment would It's a balance between rot and visibility, right? Unless you code with commit messages always visible, you have to go out of your way to look at them. If the interesting line changes even a little bit, you could hide the commit message explaining everything with one that explains a small change. If I could only have one, I would rather have comments visible in the code, and control they rot through change review, but of course finding a balance between both is the best.
- saagarjha 7y ago
  > Unless you code with commit messages always visible I do this when tracking down bugs or trying to figure out the design of a particular component.