3 ms·

The argument for squashing is that minor updates like spelling, renaming, or test fixes during initial development can really clutter the history if they each h

The argument for squashing is that minor updates like spelling, renaming, or test fixes during initial development can really clutter the history if they each have a commit. Many would rather see the actual change "Update X to use Y instead of Z" in the history, and minor details like "Fix mock in XTestCase" or "Perform renames from code review" within that single commit. I'm sort of agnostic on this issue, but I do feel the article's author kind of overstated it here. Say 5 to 10 commits of this size were squashed together. Git bisect would've taken him 90+% as far and he'd have to read code or manually trial and error changes just slightly more. The binary searchable problem space would be slightly smaller, and the linear manual effort space slightly bigger. Less good, but really not that big of a deal.

twic 6y ago
For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates. If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change, so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundling a load of refactoring and cleanup in there is a significant speedbump for my understanding. Years ago, a sage pointed out the argument for squashing is really an argument for better tools. Imagine if you could flag commits as being of two types - major/minor, significant/insignificant, feature/refactoring, foreground/background, melody/rhythm, etc. Then imagine if the tools would by default hide, roll up, or otherwise de-emphasise the commits of the latter kind. This whole apparent dichotomy would go away in a flash. This idea is floating around in the Wiki world. I believe it was Ward's Wiki that introduced a 'minor edit' checkbox in the editor; if a change was marked as a minor edit, it wouldn't be show on the recent changes feed. You can imagine other ways to get somewhere similar. For example, you could have a special kind of commit that just groups a previous run of commits, and the tools could show that and hide the members of the group by default. There are probably many other ways to do this.
- tasogare 6y ago
  Interesting idea, however this could also be easily abused for nefarious use.
- WorldMaker 6y ago
  There is a special kind of commit that "just groups a previous run of commits", it is called a merge commit. Tools like --first-parent can restrict git log/git blame to just "top level" merge commits. The only real change is that isn't the default in most tools, but they don't have to show the full graph, they could better focus on a specific depth by default.

twic 6y ago

For me, it's the other way round: minor updates like spelling, renaming, or test fixes during initial development can really clutter the major updates. If i am making a commit that makes a complex but important change to some significant application logic, i want that commit to contain that change and only that change, so that when i have to re-read it a year later, it's completely obvious what i did and why. Bundling a load of refactoring and cleanup in there is a significant speedbump for my understanding. Years ago, a sage pointed out the argument for squashing is really an argument for better tools. Imagine if you could flag commits as being of two types - major/minor, significant/insignificant, feature/refactoring, foreground/background, melody/rhythm, etc. Then imagine if the tools would by default hide, roll up, or otherwise de-emphasise the commits of the latter kind. This whole apparent dichotomy would go away in a flash. This idea is floating around in the Wiki world. I believe it was Ward's Wiki that introduced a 'minor edit' checkbox in the editor; if a change was marked as a minor edit, it wouldn't be show on the recent changes feed. You can imagine other ways to get somewhere similar. For example, you could have a special kind of commit that just groups a previous run of commits, and the tools could show that and hide the members of the group by default. There are probably many other ways to do this.

tasogare 6y ago
Interesting idea, however this could also be easily abused for nefarious use.
WorldMaker 6y ago
There is a special kind of commit that "just groups a previous run of commits", it is called a merge commit. Tools like --first-parent can restrict git log/git blame to just "top level" merge commits. The only real change is that isn't the default in most tools, but they don't have to show the full graph, they could better focus on a specific depth by default.