3 ms·

The culture of rebasing and squashing is the enemy of DiffDebugging. When you squash, you make your deltas very big and less useful. When you rebase, you genera

The culture of rebasing and squashing is the enemy of DiffDebugging. When you squash, you make your deltas very big and less useful. When you rebase, you generally lose your deltas completely, because a rewritten history consists of commits nobody generally tried out.

eternal_braid 3y ago
The culture refers to commits like: "add tests" "track new files" "test passes" "tests compile" "temp" and not to logically independent changes.
pnt12 3y ago
Unless we're talking about different workflows, squashing works great. In my team, we merge squash our PRs, having a guideline that they should be a small increment. Here's what happrns: - when you checkout a commit, you are guaranteed to have a version that was reviewed by a person and validated by ci/cd - most commits have chsnegs with substance, instead of "log", "debug", etc Without squash, a person can push 3 commits to a feature branch, ci/cd says the last commit is OK, it gets merged, and you may get 2 commits that don't compile or cause a very basic runtime error due to some typo or whatever. (not that it could not be solved with due diligence, but that comes with higher effort too) How do you assure working commits and avoid noise without either squash or rebase?
gcarvalho 3y ago
> a rewritten history consists of commits nobody generally tried out I find the exact opposite to be true. When you merge 20 commits from a branch, you add to the history a bunch of unfinished-state checkpoints, which may not even compile individually, and that may make the search longer than it should. Also, those intermediate commits probably never were deployed as individual units. In a merge-squashed main branch all commits: * were reviewed as a single unit, but may have originated from multi-commit branches * are guaranteed to have passed the test suite * by definition, are at a ready-to-deploy state, even if they contain feature-flagged components These are much easier to bisect through. And their changeset shouldn’t be any larger than any regularly-merged branches. It’s the same unit of work, merged differently. If the PR is too large, then you’re probably lumping too much stuff together, which also leads to slower and worse code review cycles.

eternal_braid 3y ago

The culture refers to commits like: "add tests" "track new files" "test passes" "tests compile" "temp" and not to logically independent changes.

pnt12 3y ago

Unless we're talking about different workflows, squashing works great. In my team, we merge squash our PRs, having a guideline that they should be a small increment. Here's what happrns: - when you checkout a commit, you are guaranteed to have a version that was reviewed by a person and validated by ci/cd - most commits have chsnegs with substance, instead of "log", "debug", etc Without squash, a person can push 3 commits to a feature branch, ci/cd says the last commit is OK, it gets merged, and you may get 2 commits that don't compile or cause a very basic runtime error due to some typo or whatever. (not that it could not be solved with due diligence, but that comes with higher effort too) How do you assure working commits and avoid noise without either squash or rebase?

gcarvalho 3y ago

> a rewritten history consists of commits nobody generally tried out I find the exact opposite to be true. When you merge 20 commits from a branch, you add to the history a bunch of unfinished-state checkpoints, which may not even compile individually, and that may make the search longer than it should. Also, those intermediate commits probably never were deployed as individual units. In a merge-squashed main branch all commits: * were reviewed as a single unit, but may have originated from multi-commit branches * are guaranteed to have passed the test suite * by definition, are at a ready-to-deploy state, even if they contain feature-flagged components These are much easier to bisect through. And their changeset shouldn’t be any larger than any regularly-merged branches. It’s the same unit of work, merged differently. If the PR is too large, then you’re probably lumping too much stuff together, which also leads to slower and worse code review cycles.