[akoboldfrying]

I don't understand the appeal of squash commits. AFAICT, the only advantage of squash commits is a nice "linear history", but you can get that from regular old merge commits just by adding --first-parent to your `git log` command -- and you still have that additional detail available on the second-parent commit chain if you need it.

As soon as you start squashing commits, you throw away a very useful guarantee git gives you by default, which is that a given code change A is "in" a given branch B if and only if A is reachable from B. This guarantee is very helpful when debugging differences between versions, e.g., in figuring out which commits I've made locally are actually running in a shared environment like staging/UAT.

[jen20]

The point is it enables bisect workflows that don’t suck. If half the commits in a tree are “fix misc derp” or “test passes now”, that workflow isn’t possible.

The short term and long term view of the work should be different.

[u801e]

> The point is [the squash commit method] enables bisect workflows that don’t suck. If half the commits in a tree are “fix misc derp” or “test passes now”, that workflow isn’t possible.

The problem with squash commits is that they tend to make changes to more files and make changes to more lines in a given file. This makes it harder to revert changes after more changes have been applied to the main branch. In contrast, organizing commits into a set of logical changes necessary to implement a feature in a given branch makes it much easier to revert one of those commits even after other feature branches have been merbed into the main branch because the commits affect one or just a few files and not many changes in a file).

[jen20]

Indeed, but trying to revert lots of tiny commits in one unit is no better.

Really it just requires discipline to either make entire related changes as patches or pull requests, which doesn’t matter.

The result of a pull request should be the equivalent of having built a single patch to start with, just with better review tooling.

[u801e]

> Indeed, but trying to revert lots of tiny commits in one unit is no better.

You shouldn't have to revert a lot of tiny commits if the bug is due to just one of those commits.

> The result of a pull request should be the equivalent of having built a single patch to start with, just with better review tooling.

In my experience, features take more than one commit to implement. The merge commit provides a way to group those multiple commits so that you can see all commits that went into implementing a feature.

If you're trying to make pull requests that are like small commits, then a feature branch becomes

    first-commit
    first-pr-merge
    second-commit
    second-pr-merge
    third-commit
    third-pr-merge
    ...
    nth-commit
    nth-pr-merge

with commits and their associated merge commits for other features interspersed with your set of commits.

Which basically introduces a lot of merge commits (effectively doubling the number of commits) where the first parent is the previous merge commit and the second parent is the single commit for that pull request. You have no way to really group related commits that were used to implement a feature since there's no merge commit that groups them all together. In that case, you could halve the number of commits by dispensing with merge commits entirely and just adding the #PR-number in the commit message to link to the PR discussion.