Hacker News new | ask | show | jobs
by u801e 986 days ago
> 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).
1 comments
jen20 986 days ago
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.

link
u801e 986 days ago
> 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.

link