To me it is most important that the commit is focused only on one thing, and not mix any unrelated changes together.
We develop a Rust based tool HighFlux [1] which simplifies/automates working with git.
In this workflow you create a feature branch for every feature you work on and it automatically commits all changes to this branch.
After code review the branch gets merged as a squashed merge to have it in a single commit in the history.
How do you keep you commit focused on one thing if you squash?
Often, before you reach to the point where you can make the change you want, you need to make side-changes which are not a strict part of the feature you're building.
I agree this happens quite often. Since Highflux automatically commits changes to the current branch it is extremely easy to switch to a different branch with just one click (or CLI command). (so no stashing / dealing with untracked files is needed)
Then you can implement the side change separately and then switch back again to your first feature branch.
Those two feature branches are then unrelated, we are planning to add stacked changes in a future version.
The ad is about a git tool (hiflux) that happens to be written in Rust. That is perfectly relevant in this context. Rust is also a good language to write such tools (as is Go). I understand why Rust evangelism can be a bit tiring. But the opposition to it shouldn't try to imitate the same quality.
We develop a Rust based tool HighFlux [1] which simplifies/automates working with git. In this workflow you create a feature branch for every feature you work on and it automatically commits all changes to this branch. After code review the branch gets merged as a squashed merge to have it in a single commit in the history.
1: https://www.highflux.io/