Now, if you think "Don't make any backward incompatible changes." is your answer, you are missing the point. Yes, that's a nice goal to aim for, and we are doing our best to minimize the need for such changes. But you still need to think about what to do when you need to make an exception to that rule, and saying "Don't" is merely refusing to think things through.
For example, in 1.6.0, we finally stopped installing many subcommands (e.g. git-cat-file) in users' $PATH, in response to long-standing complaints from many users, and having warned about the change for two years. The workaround for people who have scripts that used the "dashed form" subcommands is simple, and many people may have known that the change would eventually come, but nevertheless, they found that the change did hit them by surprise. Main complaints after 1.6.0 was released were that the change could have been advertised better.
It however is harder to reach and give early warnings to the user community, once your software is used by wide audience, than people would think. Developer mailing lists of many projects that use git do not accept messages from non-subscribers, and there is no comprehensive list of projects that want/need to receive important messages.
So I am asking for people from projects that use git as their SCM of choice to help me (and others) with a way to spread the word when needed. There is a ProjectContacts page prepared at Git Wiki site.