We in the industry as a whole, should really stop advocating one approach as the "new hot stuff" (and your title implies this). Especially knowing that there will be people using this without understanding what they are actually doing. And then suddenly you are looking at a git history for a file and see the same change popping up twice with other commits in between, because of a git merge long-living into feature in between two squashes.
Now, me - the bug hunter - can't make sense any more of what happened to the file and what was missed. Combine this with commit messages that only describe WHAT was done, not WHY (I can read the what in git log -p thank you) and you're at a loss why Jack "corrected an error" that looked to be totally legit and is now causing issues downstream in different parts of the code. In that squash are tons of other files and changes, that I now need to consider as part of the problem, instead of the more isolated commits the bug was part of. The timeline is also not as a real rebase would be, especially when people are made afraid of rebase, so they merge development into feature, but then squash as well "cause it makes history more concise" or whatever the reasoning is. Very simply put: if you squash 40 commits, how useful is git bisect to isolate a problem?
Again - it boils down to knowing how git works, how version control works, what tools it has. Next to your IDE, it's the number one tool you use, yet you'll be hard pressed to find devs who can use it for more then just a way to share and backup code.
Another - totally different thing to consider:
If you're a remote working freelancer, have the courtesy to not squash. It hides commit times. So there's no way for me to verify if you actually worked the time you invoiced and a good CFO will ask me that question.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We in the industry as a whole, should really stop advocating one approach as the "new hot stuff" (and your title implies this). Especially knowing that there will be people using this without understanding what they are actually doing. And then suddenly you are looking at a git history for a file and see the same change popping up twice with other commits in between, because of a git merge long-living into feature in between two squashes.
Now, me - the bug hunter - can't make sense any more of what happened to the file and what was missed. Combine this with commit messages that only describe WHAT was done, not WHY (I can read the what in
git log -pthank you) and you're at a loss why Jack "corrected an error" that looked to be totally legit and is now causing issues downstream in different parts of the code. In that squash are tons of other files and changes, that I now need to consider as part of the problem, instead of the more isolated commits the bug was part of. The timeline is also not as a real rebase would be, especially when people are made afraid of rebase, so they merge development into feature, but then squash as well "cause it makes history more concise" or whatever the reasoning is. Very simply put: if you squash 40 commits, how useful isgit bisectto isolate a problem?Again - it boils down to knowing how git works, how version control works, what tools it has. Next to your IDE, it's the number one tool you use, yet you'll be hard pressed to find devs who can use it for more then just a way to share and backup code.
Another - totally different thing to consider:
If you're a remote working freelancer, have the courtesy to not squash. It hides commit times. So there's no way for me to verify if you actually worked the time you invoiced and a good CFO will ask me that question.