Coping with the pull-before-you-push model

[Joshua Jensen <jjensen@workspacewhiz.com>]

  After a deployment of Git on a centralized server at my place of 
business, the largest amount of grumbling has been with the 
pull-before-you-push model.  Coming from the file-centric Perforce where 
you need only have latest of just the files you are submitting, the 
pull-before-you-push model has really been a pain in the neck for a 
large team.

Even with topic branches being used, merges to master occur frequently.  
It can really be a frustrating battle to get your merged branch pushed 
to the central master branch.  In the time it took you to pull, test, 
and push, someone has probably already pushed before you.  To cope with 
this, people will pull, not bother testing, and immediately push their 
changes.  Yes, this could result in build instability, but it is 
considered better than never being able to make your change live.

(Let's ignore what we should or shouldn't be doing as far as 
'development practices'.  :)  We're solving the problems one step at a 
time...)

Gerrit provides a compelling model where branches are pushed to the code 
review server in the form refs/for/master, and the given push will 
always succeed.  Code reviews are performed, someone sets the verified 
bit, and the change is submitted and merged to master by Gerrit itself 
in a queued fashion.  Unfortunately, its general "requirement" to squash 
your branch down to a single commit is, possibly, a showstopper.  If it 
treated a branch merge as a group of commits that MUST stay together, 
that would be perfect.

What other tools are out there that would let users successfully push 
their branch to the server (without having the HEAD master commit), and 
the push would be automatically merged to the master branch?

Is there another workflow that is successful for your large(-ish) 
enterprise team?

Thanks for your insights!

Josh