[simias]

I've already made a similar comment elsewhere in this discussion but I really don't get why most of these things is better stored in a commit message than, say, as a comment in the code itself, which will always be here even if I'm just browsing through the code by following a call stack or if the file gets copied into another project for instance.

I don't "git blame" all the code I read all the time, and even if I did one small refactor or variable renaming is enough to make it tricky to track the original change back. Comments are forever.

[xorcist]

Comments and commit messages are complementary. The commit message describes the changeset and includes things like the above, the whys and the necessary context to understand the change. The comment describes the actual code as it is, and should describe how it works and how it interfaces with other code. Comments tend to be, as you say, forever while the code changes.

Both are well worth the time to write. Nicely written ones might even take a full minute or two to write, but how many cleaned-up and rebased commits does one produce in a day? A few, at most, unless they are absolutely trivial. Those minutes per workday are well spent.