On Sun, Jun 9, 2013 at 1:06 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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? If you have a code-base with 100 functions, 10 of which make sense in a public library, instead of going ahead to fix those 10 functions, it makes sense to *first* separate those 10 functions, and *then* clean them up for public usage. But let's assume that Jeff is right and this is not the first step. It doesn't matter; I already started that step and created builtin/lib.a. Are you going to throw away that because it's not "the first step"? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html