Re: Coping with the pull-before-you-push model

>> This _is_ compelling, but even if it would work within the company I work
>> for, it is such a dramatic shift in workflow that I am certain it could not
>> be done in one fell swo
>>
> The big difference between commercial work and open source projects
> like git and linux is that the latter have just one constraint -
> quality whereas the former also have budgets and schedules to worry
> about. Unintegrated crap code has cost the open source project almost
> nothing. Commercial enterprises, on the other hand, pay lots of money
> for people to develop code whether it is crap or otherwise. The idea
> of leaving expensive code unintegrated causes management paroxysms of
> concern that are hard to ignore - a tool that blindly integrates crap
> code automatically is a soothing balm for such people. Hence the
> resistance to tools like git that encourage a maintainer role and,
> implicit in that, the possibility of review that might result in crap
> code being exposed for what it is.