From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Kastrup Subject: Re: [PATCH 0/4] remote-hg: more improvements Date: Thu, 15 May 2014 00:30:47 +0200 Message-ID: <87a9akro14.fsf@fencepost.gnu.org> References: <1399169814-20201-1-git-send-email-felipe.contreras@gmail.com> <536a83097302f_76ff7a52ec6c@nysa.notmuch> <536a999e2c0c_76ff7a52ec1e@nysa.notmuch> <536ad9601b73b_3caaa612ecdc@nysa.notmuch> <87mweku2pt.fsf@fencepost.gnu.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Philippe Vaucher , "git\@vger.kernel.org" To: Junio C Hamano X-From: git-owner@vger.kernel.org Thu May 15 00:30:55 2014 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WkhhO-00014B-T8 for gcvg-git-2@plane.gmane.org; Thu, 15 May 2014 00:30:55 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753593AbaENWau (ORCPT ); Wed, 14 May 2014 18:30:50 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:57411 "EHLO fencepost.gnu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753155AbaENWas (ORCPT ); Wed, 14 May 2014 18:30:48 -0400 Received: from localhost ([127.0.0.1]:56451 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkhhH-0007uB-N0; Wed, 14 May 2014 18:30:48 -0400 Received: by lola (Postfix, from userid 1000) id 3673BE0BD9; Thu, 15 May 2014 00:30:47 +0200 (CEST) In-Reply-To: (Junio C. Hamano's message of "Wed, 14 May 2014 15:24:51 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Junio C Hamano writes: > David Kastrup writes: > >> Philippe Vaucher writes: >> >>> Thanks for the explanation. I think it underlines well the A) >>> technical issues (quality commits) and the B) social issues (ability >>> to communicate in a friendly way & respond constructively), which we >>> discovered are both *essential* for contributing to git. >> >> I'm not entirely convinced of that: there is something akin to drop-dead >> gorgeous code: code that is so well done that it would not matter with >> regard to its maintenance whether or not its author dropped dead because >> it's both done well as well as documented in a manner where the original >> author could not offer significant additional help. > > I would have to say that you are living in a fantasy land. During > the entire life of Git, I do not think I ever saw such a code that > is perfect from the get-go and did not require any maintenance to > adjust to the changing time. You are attacking a straw man. "where the original author could not offer significant _additional_ help" does not at all equate "does not require any maintenance". -- David Kastrup