4 ms·

I think you're missing the point. How a lot of projects operate is that the commits on PR branches are completely pointless since they will be deleted when the

by slaymaker1907 3y ago

I think you're missing the point. How a lot of projects operate is that the commits on PR branches are completely pointless since they will be deleted when the PR is merged and the PR description will become the real commit message for the commit on the main branch from the squash-merge. The trouble is that Git is trying to do two things at once. It's trying to do remote synchronization as well as change tracking all at once. An alternative is just to do "git commit --amend" every time you want to fix some small bug, but that has downsides in preventing reviewers from seeing what has changed between PR iterations as well as preventing you from going back to an earlier point in time for some branch. When you have less than a dozen commits, it is completely reasonable to just look at diffs and timestamps to determine which commit you want to go back to.

cedws 3y ago
In my opinion, squash merges are evil and enabled only out of necessity because people fill their PRs with spam commits and won't bother to fixup/squash themselves. There are very good reasons not to enable squash merges. For example, code formatting changes should almost always be in a commit of their own and not squashed together with a refactor or new feature. If you bundle these changes together, git blame output becomes a mess and it's more difficult to distil what the actual changes were in a commit. Crafting intelligent commits is a skill in itself that more engineers need to learn.
- slaymaker1907 3y ago
  Non-squash commits are kind of a nightmare to actually implement securely. You need to make certain that all the commits are properly assigned to an actual person (no impersonation) which would involve implementing commit signing infrastructure which a lot of orgs don’t want to do. It can also get confusing as a reviewer if people do any rebasing after submitting the PR.

cedws 3y ago

In my opinion, squash merges are evil and enabled only out of necessity because people fill their PRs with spam commits and won't bother to fixup/squash themselves. There are very good reasons not to enable squash merges. For example, code formatting changes should almost always be in a commit of their own and not squashed together with a refactor or new feature. If you bundle these changes together, git blame output becomes a mess and it's more difficult to distil what the actual changes were in a commit. Crafting intelligent commits is a skill in itself that more engineers need to learn.

slaymaker1907 3y ago
Non-squash commits are kind of a nightmare to actually implement securely. You need to make certain that all the commits are properly assigned to an actual person (no impersonation) which would involve implementing commit signing infrastructure which a lot of orgs don’t want to do. It can also get confusing as a reviewer if people do any rebasing after submitting the PR.