Hacker News Reader

Comment by cratermoon | Hacker News Reader

> In my experience squash messages combine the messages of the commits they consolidate.

I believe they do, by default, but the developer gets to modify. In other words, if I squash 3 commits, the git cli will set the resulting message to be a combination of all 3, but opens an editor to let me change it.

I'm not for or against any git merge/squash/rebase flow on technical grounds, but I do want every message in the commit log to stand on its own. In other words, I agree 100% with the intent of what DNSimple does, and if this is how they chose to do it, I have no disagreement. What matters to me is outcome: the commit history as a useful 'document' for how we got to where we are now.

View on HN

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.

> 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.

Bug 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.

Reply on news.ycombinator.com