A great gain from a systematic approach of creating clean history is a better understanding and higher discoverability of issues.
Looking into change history is rare. But designing your changes, being deliberate, structured allows for easier and safer reviews and merges. And spotting issues early is always cheaper and better.
It also helps tremendously in determining what changed between versions. And when necessary finding and reverting regressions.
Cleaning up your history before making a PR can make it easier to review so I always try to do that, but it’s not something that should be over done because it can quickly eat up more time than its worth if you go overboard
To a degree, if pull requests are small enough, then yes.
Often, a changeset includes different aspects and concerns though, and individual commit messages allow you to document and reason them. Squashing makes you lose the concern separation.
When reviewing, even relatively simple changes separated into their concerns helps me a lot.
It’s a matter of preference and necessity, and the changeset and it’s environment at hand.
Not squashing before review, squashing on merge (i.e. after review). Squashed merges make these easy, regardless of whether the original commits in the pull request were messy:
do the things the way I like because I can think of three reasons it’s technically superior but not practically useful to do so" people.
Camp I was talking about. You’ve your reasons, you’ll bikeshed about it for months and no one gets anywhere and no one is happy aside from the people that enjoy the arguments
A great gain from a systematic approach of creating clean history is a better understanding and higher discoverability of issues.
Looking into change history is rare. But designing your changes, being deliberate, structured allows for easier and safer reviews and merges. And spotting issues early is always cheaper and better.
It also helps tremendously in determining what changed between versions. And when necessary finding and reverting regressions.
Cleaning up your history before making a PR can make it easier to review so I always try to do that, but it’s not something that should be over done because it can quickly eat up more time than its worth if you go overboard
Doesn’t squashing on merge achieve exactly the same thing? (As long as pull requests are kept small, of course.)
To a degree, if pull requests are small enough, then yes.
Often, a changeset includes different aspects and concerns though, and individual commit messages allow you to document and reason them. Squashing makes you lose the concern separation.
When reviewing, even relatively simple changes separated into their concerns helps me a lot.
It’s a matter of preference and necessity, and the changeset and it’s environment at hand.
Not squashing before review, squashing on merge (i.e. after review). Squashed merges make these easy, regardless of whether the original commits in the pull request were messy:
Yes, this is the
Camp I was talking about. You’ve your reasons, you’ll bikeshed about it for months and no one gets anywhere and no one is happy aside from the people that enjoy the arguments