When will `git pull --rebase` get me in to trouble?

Question

I understand that when I use git pull --rebase, git will re-write history and move my local commits to occur after all of the commits in the branch I just pulled from.

What I don't understand is how this would ever be a bad thing. People talk about getting in to trouble with git pull --rebase where you can end up with a branch that other people can't pull from. But I don't get how that's possible since all you're doing is replaying your local, not-yet-public, commits on top of the branch you pulled from. So, what's the problem there?

Answer 1

If nobody has pulled from you, and you have not pushed your commits (before rebase) anywhere else, then you are theoretically okay. However, Git is designed to handle merges well and you may find there's less work overall if you pull and merge instead of pull and rebase.

Answer 2

It is only an issue if you have only published (pushed) some of your commits, because they would be harder to merge to other repos which have already those commits. Since their SHA1 have changed, Git would try to replay them again on those repos.

If you have not (pushed any of those commits again), any rebase should be safe.

So the issue here is: are you sure that all the local commit you are rebasing are still actually... local?
And are you sure of that 'git pull --rebase' after 'git pull --rebase'?

If you are working on a 'private branch' (a branch that you never pushed, but only merge or rebase on a public branch, one that you will push), then you are safe to rebase that private branch any time you want.

In the end, it all depends on the workflow of merge you have chosen to establish.

Answer 3

Consider this situation (one of many):

Someone else pushes changes to a central repo that occur after some local changes you have. You pull those changes, rebase yours into the flow and push it back, overwriting the original commit history. When that other person goes to pull next time, they will be unable to pull without first rewinding back, as the commit history and hashes no longer match.

I find rebase to be very useful in situations where you are already sure your new commits occur after the last remote change, as you avoid an unnecessary branch merge (which can look messy in history).

Answer 4

Remember that Git is a distributed source control system. People don't have to pull from the central repository that you're pushing to - in certain workflows they can pull their changes directly from you. In those cases, rewriting your history can certainly cause the problems you're talking about

Answer 5

Commit to a branch. Push. Merge up to another branch (say you're maintaining two baselines, a patch branch and a new-development branch). Realize other commits have been pushed to the server branch yours is tracking. pull --rebase. Suddenly you've re-made each of the commits against the new hash - and destroyed the merge commit.