Nothing wrong with pushing directly to main line. In fact, that's what I prefer and is basically required if you want to practice Continuous Integration.
Looking at the commit history to find the most relevant description isn't really the best approach to diagnosing issues. It's the second or third step. You should locate where the problem occurs, and only then look at the history. Just because somebody changed part of the code which now causes a problem doesn't mean that this change introduced a problem, it might just uncovered a new problem.
With small and frequent ACID-style commits with proper descriptive commit messages you will be able to reason about why changes were made, and possibly the reasoning behind it. Things which get lost with a squash commit, because then you don't get information about which major thing was changed but not why the smaller parts changed. What was changed is also visible from the changed code.
With software development recording the why is more important than recording the what. Because the latter we already solved.
To summarize your and my point:
If too many commits is a problem, then you might be working wrong.
Squashing commit does not solve this problem, it just tries to hide it under a rug.
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.
Nothing wrong with pushing directly to main line. In fact, that's what I prefer and is basically required if you want to practice Continuous Integration.
Looking at the commit history to find the most relevant description isn't really the best approach to diagnosing issues. It's the second or third step. You should locate where the problem occurs, and only then look at the history. Just because somebody changed part of the code which now causes a problem doesn't mean that this change introduced a problem, it might just uncovered a new problem.
With small and frequent ACID-style commits with proper descriptive commit messages you will be able to reason about why changes were made, and possibly the reasoning behind it. Things which get lost with a squash commit, because then you don't get information about which major thing was changed but not why the smaller parts changed. What was changed is also visible from the changed code.
With software development recording the why is more important than recording the what. Because the latter we already solved.
To summarize your and my point:
Squashing commit does not solve this problem, it just tries to hide it under a rug.