3 ms·
I guess I haven't worked on a project important enough where the history is more important than the current state. Usually it's more like it might be useful to
by jakeva 5y ago
I guess I haven't worked on a project important enough where the history is more important than the current state. Usually it's more like it might be useful to gain perspective by looking at the history, only to find it was a conflicted merge or the comment contained no useful info anyway ("Clean up", or "Fix this feature").
Even if it tried really hard to document the purpose of the change, I've rarely gotten more from a commit message than the content of the code changes in the commit.
- cratermoon 5y ago> I've rarely gotten more from a commit message than the content of the code changes in the commit. That's generally true, but the article is specifically about how a rule/convention/expectation in DNSimple workflow ensures, or purports to ensure, that commit messages are informative. My experience is that it doesn't really matter if the explanation is in the commit message, a bug tracker ticket, or the team wiki, as long as I can go from commit -> understanding, it's good. I also say that if a programmer can't craft a useful commit message, they probably don't have good documentation for it elsewhere.
- erik_seaberg 5y agoBug tracker searches are generally pretty poor, even if your team never migrated from one to another. During a 3 AM outage, I need to grep git log for affected files to find likely root causes from 2018 or whatever. I want reviewers to insist on a commit message that says what’s going on here and why. Not a full design doc, but enough to narrow down which commits are related to something. Please don’t make me open a hundred bug tracker pages that may or may not still exist.