[erydo]

Agreed.

A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them.

If a developer consistently pushes commits like this, they should be guided by their team lead to understand their importance. But if over time they refused to improve them, in many cases that would eventually be fireable. Commits are the technical paper trail: whether used when diagnosing issues, merging, compiling release notes, or whatever. Making the messages clear is extremely important.

[OJFord]

    > But then rebase, squash, and edit the commits before
    > sharing them.

And then realise that doing it properly in the first place most definitely would not have been a slow-down!

[rev_bird]

This is pretty simple to do outside of die-hard "continuous integration" shops -- most of the time I can just do git rebase -i HEAD~4 (where '4' is the number of little dumb commits I made) and squash them all into the first commit.

But if I made a few commits, then pulled in someone's changes, then made a few more... well... http://xkcd.com/1597/