`squash` is a tool and it's neither good nor bad; it needs to be applied where it makes sense.
The title is indeed click-baity. It would have been more interesting to read that the bug/mistake was caused as a result of squashing. It's not the case and I take issue with the way the author describes his commits.
The problematic commit is described "Extract CreateTokenValidationParameters method", without an explanation of why the refactoring is necessary or what problem is it solving. It looks like it is improving code readability, but it doesn't go as far as fixing the more glaring issue with global variables. Other commit messages seem to follow the same pattern.
In other words, the commit:
- has minor code readability improvements
- contains no useful message for the future programmer (why is it needed?)
- provides no new functional feature/improvement/business value
- is later found to contain a bug
I find squash/rebase/cherry-pick useful when reviewing my work and deciding what should go in the current pull-request. For example, a refactoring might be postponed for later if it is deemed too time-consuming or irrelevant to the current PR. Or, one can squash logically related commits together, add a useful message and merge them separately. The resulting commit log will still be bisect-able.
For beginners: there's a very good article with tips for Git Commit Messages[0] that helped me have git histories I enjoy reading.
[0] https://chris.beams.io/posts/git-commit/#why-not-how
The problematic commit is described "Extract CreateTokenValidationParameters method", without an explanation of why the refactoring is necessary or what problem is it solving. It looks like it is improving code readability, but it doesn't go as far as fixing the more glaring issue with global variables. Other commit messages seem to follow the same pattern.
In other words, the commit:
- has minor code readability improvements
- contains no useful message for the future programmer (why is it needed?)
- provides no new functional feature/improvement/business value
- is later found to contain a bug
I find squash/rebase/cherry-pick useful when reviewing my work and deciding what should go in the current pull-request. For example, a refactoring might be postponed for later if it is deemed too time-consuming or irrelevant to the current PR. Or, one can squash logically related commits together, add a useful message and merge them separately. The resulting commit log will still be bisect-able.
For beginners: there's a very good article with tips for Git Commit Messages[0] that helped me have git histories I enjoy reading.
[0] https://chris.beams.io/posts/git-commit/#why-not-how