From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: [PATCH 2/2] Move sequencer to builtin Date: Sun, 9 Jun 2013 14:22:46 -0400 Message-ID: <20130609182246.GE810@sigill.intra.peff.net> References: <20130609043444.GA561@sigill.intra.peff.net> <20130609175554.GA810@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Felipe Contreras , Duy Nguyen , Git Mailing List , Junio C Hamano , Brandon Casey , Jonathan Nieder To: Ramkumar Ramachandra X-From: git-owner@vger.kernel.org Sun Jun 09 20:22:55 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 1UlkGU-00006B-JB for gcvg-git-2@plane.gmane.org; Sun, 09 Jun 2013 20:22:54 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751561Ab3FISWu (ORCPT ); Sun, 9 Jun 2013 14:22:50 -0400 Received: from cloud.peff.net ([50.56.180.127]:37332 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993Ab3FISWu (ORCPT ); Sun, 9 Jun 2013 14:22:50 -0400 Received: (qmail 19325 invoked by uid 102); 9 Jun 2013 18:23:40 -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; Sun, 09 Jun 2013 13:23:40 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Sun, 09 Jun 2013 14:22:46 -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 Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote: > Jeff King wrote: > > I already mentioned elsewhere that I think it would be fine to massage > > libgit.a in that direction. I even joined the conversation pointing out > > some cases where Felipe's ruby module would break. But I do not think > > that moving code in and out of libgit.a is an important first step at > > all. That is simply code that no library users would want to call, and > > is easy to deal with: move it out. The hard part is code that users > > _would_ want to call, and is totally broken. Patches dealing with that > > are the hard obstacle that people working in this direction would need > > to overcome. But I do not see any such patches under discussion. > > Forget the rest; this makes it clear. Thanks, and sorry for all the confusion. > > So, reorganization is not the first step. Can you please post an > example patch illustrating what needs to be done, so we can follow? Sorry, I don't have patches. It is a hard problem for which I do not have the solution, which is kind of my point. For the record, I am not _against_ any code organization that might be useful for lib-ification later. I just do not see it as an interesting step to be discussing if you want to know whether such a lib-ification effort is feasible. -Peff