What happens when you rewrite history of a public branch?

Question

I read everywhere that rewriting history of commits that have been published is bad and will 'break' the repositories of the other developers.

I have been unable however to find details about what exactly will break, and how it can be fixed.

So, if I was to rewrite history and git push --force, what should I tell the other developers to do in order for them to get up-to-date?

Answer 1

This is probably the best explanation I have seen: http://git-scm.com/book/ch3-6.html#The-Perils-of-Rebasing

The short answer is that other developers would pull down the modified public repository and try to merge those changes in with their current work as appropriate. Because the most recent ancestor has likely changed this merge can be complex and may need to be performed manually. A rough example follows:

Developer A makes several commits and pushes them to the server. Developer B then merges those commits into their local branch (or potentially branches from one of those commits). Developer A decides to rebase their old commits and push up the results to the server.

This effectively drops the commits from the server that developer B was using and replaces them with largely identical commits with different identifiers.

Now if developer B pulls down from the server again they need to merge the post-rebase commits into their work, effectively merging the same changes in twice.

If developer A removed commits or amended commits in the rebase process then developer B has a significantly more complicated merge to deal with.