4 ms·
Reality could also have been: the commit message wasn't as helpful. Or the message would have been but the file was moved, copied, the indentation level changed
by jkrems 13y ago
Reality could also have been: the commit message wasn't as helpful. Or the message would have been but the file was moved, copied, the indentation level changed, or any number of things that destroys the connection to the original comment. The article sounds like it advocated treating the commit message as the primary means of documentation - which is hardly a good practice. Meaningful identifiers/function names, and comments for non-obvious code should come first. If someone prioritizes elaborate commit messages and a clean history before good code, the techniques outlined in the article might be useful, for sure. But it says: "A project’s history is its most valuable documentation." - which is, frankly, not true for most projects. And if it is true, it's a bug, not a feature.
- etler 13y agoI did not interpret the article as being git should be a primary source of documentation at all. I have a hard time seeing which part of the article implies that. I think he's just pointing out how it's another tool you can use.
- jpatte 13y agoFrom the article: A project’s history is its most valuable documentation. (...) The quality of this documentation, however, relies heavily on the diligence of the people involved while writing commit messages. Requiring such diligence when writing commit messages, while at the same time allowing the same people to write opaque code as shown in the example, would be absurd.