4 ms·

In my experience squash messages combine the messages of the commits they consolidate. And the actual branch merged still exists, I don't buy hardlined stances

by jakeva 5y ago

In my experience squash messages combine the messages of the commits they consolidate. And the actual branch merged still exists, I don't buy hardlined stances against squashed merges.

cratermoon 5y ago
> 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.
- 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 ago
      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.
gouggoug 5y ago
That would be fine if the only important information in a commit was the message. But that's not the case. A commit gives you a message, but also a specific line of code and its surrounding context. The message is just one more bit of information (an important one!). By squashing, maybe you keep the messages, but without their associated changeset (which you lost when you squashed), these messages are of poor to null value.

by jakeva 5y ago

In my experience squash messages combine the messages of the commits they consolidate. And the actual branch merged still exists, I don't buy hardlined stances against squashed merges.

cratermoon 5y ago

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

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

gouggoug 5y ago

That would be fine if the only important information in a commit was the message. But that's not the case. A commit gives you a message, but also a specific line of code and its surrounding context. The message is just one more bit of information (an important one!). By squashing, maybe you keep the messages, but without their associated changeset (which you lost when you squashed), these messages are of poor to null value.