3 ms·
I would say that this is a good argument for linearizing the history by rebasing, but certainly not for squashing. Git bisect can only narrow you down to the s
by mumblemumble 6y ago
I would say that this is a good argument for linearizing the history by rebasing, but certainly not for squashing.
Git bisect can only narrow you down to the scale of your commits. If you do infrequent, large commits, it's not very useful. If you do frequent, small commits, it's great. If you do frequent, small commits and then squash them into infrequent, large commits, it's not very useful.
There are plenty of reasons to squash (and, personally, I generally think they outweigh the arguments against), but this is not one of them.
- xorcist 6y agoSquashing is a form of rebasing. Nobody suggests commits should be too large to be useful, just that they should form coherent changes. Preferably self contained enough to be useful in their own. When you do frequent small commits, unless you are superhuman the majority of them false starts or contains errors. Squashing these useless commits makes the history understandable, and enables the use of tools such as bisect. That's what "please squash before merge" means. It does not mean you should do rebase instead of merge. There may be good reasons for that too, sometimes, but that's not the point here. Should you wish to enforce a linear history, it is still just as important to squash undesired commits.