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)
@finestructure@fork_dev It makes reverting features easier if they are bad. I don’t remember the exact issue but there is something weird about re-reverting (ie adding the original thing back in after a revert) if you are using merges too.
Bisecting is great, but bisecting to the feature merge and then delegating to the author is often easier, as they have the context that the release manager may not.
@cjwirth The only difficulty reverting a non-squashed merge is that you need to pick the ancestor. However, here as well tooling has your back. Fork for example picks the right one by default (plus it's easy to just try each) and then it's like any other revert.
Of course, once you revert that merge you have everything squashed. Alternatively, you could revert the individual commits in reverse order but that's probably hardly worth the effort.
@finestructure@fork_dev And if you really need that history, it’s still all there in GitHub. Yes, git != GitHub but in practice our workflow is so tied to GitHub that it’s a fine assumption that it will be there.
@finestructure@fork_dev@ctietze I’ve been saying this for years (it’s just a tooling issue), but everyone looks at me like I’m from mars. I think almost every git client I’ve used in the last 10 years has had such a feature. Normal merge commits also get collapsed visually in sublime merge (my current git tool; used Fork previously). Is everyone just using a CLI that can’t do anything but a linear log?
@finestructure Merge commits on active repositories make history basically unreadable, but then rebase commits erase all commit signatures, which makes squash the only practical option. Also incentivises making PRs smaller.
merge commits are kind of ugly in any tools I’ve seen.
I like the option to squash and have one commit per unit of work (ticket). Makes branch commits feel like lightweight checkpoints that later gets squashed - “oops” and “WIP” all you want, squash into a clean commit after code review.
@finestructure in my experience when you don’t squash merges you end up with a lot of commits on the main branch that don’t actually build or build but have test failures because that’s how development goes: you make a bunch of mistakes first and then you fix those, but you only merge when the top of the branch is good.
@cocoafrog Look at my screenshot - these commits •don't• end up (directly) on the main branch. That's the beauty of it. You can roll up the merged branch and it's as if it was squashed. Yet the whole history is still there.
@finestructure I’m a weirdo who, prior to putting up a PR, carefully rewrites my branch’s changes into organized commits that represent easy-to-follow logical changes rather than the chaotic actual history of how I got there.
For the 99.99% of normal people who don’t spend their time doing that, I think a squashed commit is easier to understand in the history than the chaos of dozens of little adjustment commits and merges from other branches.
@tmcfarlane@finestructure A well curated history is definitely better, but I think people squash when they don’t have the time or ability to create a well curated history.
@jjoelson My main problem with the squash strategy (as enforced via GH for example) is that it forces the squash even on folks who do the work to have a good branch history.
@finestructure I vastly prefer rebase and merge in GitHub for that linear history, though I also take a lot of time authoring the commits themselves so they each have a clear thing they are fixing or improving (ie. no “oops" or "wip" commits ever — those get squashed before I even push to the PR 😅)
I don't know if its improved, but merge commits have tended to “hide” changes that it didn't see as consequential in PR diffs, whereas a rebase always shows exactly what would get committed to main.
@finestructure I think reverting a change out becomes simpler. Also I want to point out that squashed commits do not necessarily mean larger commits. It mostly means that you focus to get a complete feature/bugfix into one commit. That has the benefit that all the small commits in between (“ooops”, “oh god please ci”, “pr review”) are not part of the final history. This way you have a 1:1 relationship between feature and commit.
@fabianfett I've rarely seen squashes used like that in practice. They're just big balls. Plus of course you should just have good branch hygiene and make your work focused. That’s independent of your merge strategy!
FWIW, I often rebase out oops or trial and error commits in order to keep the branch tidy.
@finestructure@fabianfett It is still a tooling issue, I don't see why you'd ever want to throw away history.
The fixit commits are hidden exactly the same way in the collapsed mode and you could also just hide them if you wanted to, and the tool allows for that.
@fabianfett I can point you to some offline. Bear in mind that I’m not saying squashes are always bad. Sometimes it makes no difference, when the merge set was small overall. The problem is that with a squash policy you have no options when the change set is large.
@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.
@dgregor79 I hadn't even thought of this great example. I encounter that quite frequently that I make a commit which I know I'll want to revert (or cherry-pick!) later. Squash is the enemy of that.
history was important for the commits on this branch, so squash should not be used (or at least they should be squashed in a better way, by leaving this particular commit)
create another PR for the workaround and have it tracked as a different issue
@dgregor79@finestructure I get your point that: If squash isn’t expected, squash can feel weird and destroy care that you put into separate commits. However the same is true the other way as well. ☺️ I often put lots of care into my pr description but yolo my commit messages, expecting commits to be squashed in the end and the message to be taken from my pr description.
If you were aware, of the squash behavior in SwiftPM, would it have been possible to put the temp fix in a separate PR?
@fabianfett@dgregor79@finestructure I think saying "destroyed commits" is an exaggeration here. Even with squashes all of the original commits are automatically preserved on GitHub and can be easily tracked down and bisected if needed. If there are any concerns with those commits stored on GitHub, all of those branches can be cloned and stored in an external system including local clones if needed.
@finestructure if you delete merged PR branches, there's a "Restore" button displayed by the squashed merge commit and its original branch info, otherwise it's called "Delete".
@maxd Sure, I knew about that - but how does that allow me to run a bisect across the whole tree? I’d have to click through lots of PRs and on top of it I’d resurrect lots of branches for everyone in the upstream. That doesn’t seem feasible.
@finestructure@maxd That’s the great thing - you don’t need to bisect through all of them. The “bad commit” will only exist in one of those squashed commits. So you bisect to find that squashed commit, check out that branch, and bisect again on just the commits on that branch.
Bisecting might even be faster this way because you don’t have to consider all the WIP commits for every merge?
@cjwirth@maxd Ok, I can see how you can work around the lost (or obscured) history.
I'm not sure I'd want to lean on GH preserving dangling commits and resurrect the branch for everyone (it's also something you have to have permissions for - i.e. you can't bisect just any open source project for instance) but at least it's feasible.
It most certainly isn't faster than just going through the git history you already have locally, given the process. That's the power of bisect 🙂
@finestructure@maxd The compromise feature we all want is present in, of all things, bzr. There, by default, the history only shows merges or commits made directly on a branch. But at any time you can ask the various tools to show the full history merged in, and then you see every tiny commit. Maximum development history, cleanest feature history.
Add comment