From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: [Administrivia] On ruby and contrib/ Date: Sat, 8 Jun 2013 20:10:25 -0400 Message-ID: <20130609001025.GB29964@sigill.intra.peff.net> References: <20130608171513.GA28029@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Duy Nguyen , Johannes Schindelin , Greg Troxel , Junio C Hamano , Git Mailing List , Jonathan Nieder , Thomas Rast , =?utf-8?B?UmVuw6k=?= Scharfe , Michael Haggerty , Matthieu Moy , Ramsay Jones , Erik Faye-Lund , Johannes Sixt To: Felipe Contreras X-From: git-owner@vger.kernel.org Sun Jun 09 02:10:46 2013 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 1UlTDa-0008T2-03 for gcvg-git-2@plane.gmane.org; Sun, 09 Jun 2013 02:10:46 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753103Ab3FIAK3 (ORCPT ); Sat, 8 Jun 2013 20:10:29 -0400 Received: from cloud.peff.net ([50.56.180.127]:58102 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752983Ab3FIAK2 (ORCPT ); Sat, 8 Jun 2013 20:10:28 -0400 Received: (qmail 30288 invoked by uid 102); 9 Jun 2013 00:11:17 -0000 Received: from c-71-62-74-146.hsd1.va.comcast.net (HELO sigill.intra.peff.net) (71.62.74.146) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Sat, 08 Jun 2013 19:11:17 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Sat, 08 Jun 2013 20:10:25 -0400 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote: > > These are problems that can be solved. But there is a lot of work > > involved in finding these subtle bugs and coming up with fixes. I think > > you would be better off working on an implementation of git that was > > designed from scratch to work in-process, like libgit2. > > So you are in favor of never ever having an official Git library. Got it. No, I didn't say that at all. I do think that it would be more work to try to slowly massage the git code into a library-ready form than it would be to simply start with more library-friendly code and pull in bits of git.git as appropriate. That is what the libgit2 project is doing. Perhaps one day that project will reach a point where we start building git.git commands off of it or sometihng like it (for that matter, there is no reason you could not build external commands off of libgit2 right now). Would it be the "official" Git library then? I don't know. It is not clear to me what that even means. In the meantime, I think it cannot be a bad thing for libgit2 to proceed along its path, and I don't see a good reason for people not to use it. But hey, you don't need to listen to me. If you think it would be easier to make the git.git code into a library, go ahead and work on it. But I think you will find that there are a large number of hard-to-find bugs caused by implicit assumptions about global state, how file descriptors are used, and so forth. > There's a reason why the Git project doesn't use libgit2, and for the > same reason the official Ruby scripts should not use it. What reason is that? > As history indicates, the Git project will never have any pressure to > fix it's re-entrancy and re-run issues, so these issues will remain > there forever. > > Only if you allow code that exposes those issues will there ever be > any pressure to fix them. I think it is a matter of critical mass. If you were to start linking against libgit.a and 90% of it worked, you might have a reason to fix the other 10%. But I suspect it is more the other way around. -Peff