Folks who squash their #git merges, I’m curious why you are making that trade-off. I’m guessing the pro argument is a cleaner merge graph?
The big argument against it for me is that you lose granularity for git bisect. I've often been able to narrow down breakage (sometimes long past the merge) due to individual commits in the merge. If I'd merged in a giant blob all I'd have had to go by is that giant blob. (1/2)
As to the “pro” argument: tooling (like for instance the excellent @fork_dev, see the screenshot) can allow you to fold your merges so they look squashed. I feel like that's the perfect combination - overview on demand without loss of granularity. (2/2)
@fabianfett@finestructure I recently landed a PR to SwiftPM where one commit in particular was of the form “temporarily work around a bug in an old Swift compiler.” The change was otherwise nonsensical and would have been reverted trivially in the future… except that it all got squashed together with a pile of good code because that’s how SwiftPM is configured. I hate the destruction of history like that; it makes it harder to undo parts of a change when that’s needed (which is common for us), and robs us of the logical flow of how a change was introduced. I cannot be convinced otherwise.
I have a branch that says it's up to date with the upstream (fork of a repo). I'm trying to contribute a patch, but my commit history in the PR has 26 commits from things that have already been merged rather than my changes from the current head.
Is there an acceptable way to clean up that history so my PR is clean?
Manager: Lets teach a non-developer office worker how to push code to git. "It's just clicking a few buttons. I've done it before. It's not that hard."