From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joshua Jensen Subject: Re: Coping with the pull-before-you-push model Date: Mon, 13 Sep 2010 22:37:16 -0600 Message-ID: <4C8EFBFC.60409@workspacewhiz.com> References: <4C8866F9.1040705@workspacewhiz.com> <4C88F2A9.2080306@workspacewhiz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , "git@vger.kernel.org" To: Jon Seymour X-From: git-owner@vger.kernel.org Tue Sep 14 06:37:22 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OvNGj-0005zl-GF for gcvg-git-2@lo.gmane.org; Tue, 14 Sep 2010 06:37:21 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751186Ab0INEhQ (ORCPT ); Tue, 14 Sep 2010 00:37:16 -0400 Received: from hsmail.qwknetllc.com ([208.71.137.138]:50751 "EHLO hsmail.qwknetllc.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751129Ab0INEhP (ORCPT ); Tue, 14 Sep 2010 00:37:15 -0400 Received: (qmail 29574 invoked by uid 399); 13 Sep 2010 22:37:14 -0600 Received: from unknown (HELO ?192.168.1.100?) (jjensen@workspacewhiz.com@76.27.116.215) by hsmail.qwknetllc.com with ESMTPAM; 13 Sep 2010 22:37:14 -0600 X-Originating-IP: 76.27.116.215 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b3pre Thunderbird/3.1.3 In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: ----- Original Message ----- From: Jon Seymour Date: 9/9/2010 11:35 PM >> 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. My apologies for the late response. I'm not ignoring this. I am trying to process it in the context of my organization as I establish the workflows we'll be using. I may have some follow up questions soon. Josh