Of course. But when modifying another, you can commit and say,
Implemented function X. Modified Y to accommodate this new argument that's used on X... and so on
>As long as the commit messages are clear, and the code works at the end, it's alright.
I'm fine if the commit messages are clear. The problem is when squashing, some people squash and don't keep commit them clear or some even squash into one that doesn't provide any insight or clarity, 'Implemented feature Y' and you get a diff of thousands of lines that touches everything
Sometimes I need to write "Implemented function X, but evaluates the result wrong possibly because of this. Fix this first, then continue".
> The problem is when squashing, some people squash...
A single commit touching whole codebase and only says "Bug fix" (or similar) is bad. I concur.
Also commit history should have enough granularity allowing bisection and partial rewind to understand problems and other side effects.
At other time I make "transfer commits" since I'll continue development on another machine and need the latest snapshot of the code to continue.
Not all features fit into a single new function, we need to move mountains to rearrange stuff, and to keep code tidy.
As long as the commit messages are clear, and the code works at the end, it's alright.