Facebook is actually in the process of implementing server side rebasing (there’s a summary here or you can skip to to about 10:55 in the video).

In their case they have such a volume of pushes that developers are in competition to push, and they can get stuck trying to pull then push before someone else pushes and forces them to pull again.

By implementing server side rebases, pushes are simply added to a queue and processed in order, ensuring developers don’t waste time getting stuck in a push/pull loop while waiting for an opportunity to push cleanly. The majority of rebases can be performed without conflict, but if there is then the developer gets notified to manually handle the merge then submit a new push. It also helps that they have a very intensive automated testing suite (also discussed in that video) so they can have greater confidence in the integrity of their automated merging.

Having said that, this approach only has benefits because they have such a high volume of pushes. These benefits don’t exist if you don’t have contention between pushes, and merging on the server side could significantly complicate conflict scenarios.

In general it makes more sense for the pusher to handle merging because they’re in the best position to handle conflicts, and there isn’t usually any time saved by performing the process on the server side.

The basic idea behind merging is that you have to consider resolving conflicts. You cannot just automatically merge and hope the system figured out what you meant – that is mostly does this is convenient but do not get confused and think that all merges work perfectly all the time.

After merging, you will want to review the results and only if it passes the human check (and possibly compiles and runs your local tests) then you can commit with a fair hope for correctness.

You can’t do this on the server unless you log into it and treat the server as if it was your local workstation. And if you are doing that, why not do it on your local workstation in the first place!?