{"thread":{"id":"31346","subject":"libgit2 status","startedAt":"2012-08-24T14:02:43Z","lastAt":"2012-10-20T07:58:17Z","messageCount":23,"participants":["greened@obbligato.org","Andreas Ericsson","Vicent Marti","Nicolas Sebrecht","Carlos Martín Nieto","Elia Pinto","Junio C Hamano","dag@cray.com","Thiago Farina","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197772","messageId":"87a9xkqtfg.fsf@waller.obbligato.org","threadId":"31346","inReplyTo":null,"subject":"libgit2 status","fromName":"","fromEmail":"greened@obbligato.org","sentAt":"2012-08-24T14:02:43Z","receivedAt":"2012-08-24T14:02:43Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"What is the status of libgit2 WRT the overall git project? I recall\nthat there was some discussion of basing bits of git on libgit2 once it\nmatures.\n\nI ask because I'm starting a project to improve the abysmal speed of\ngit-subtree split. It's unbearably slow at the moment and as far as I\ncan puzzle out it's due almost entirely to repeated subshell invocations\nto run git commands.\n\nI was planning on doing some experiments rewriting bits of git-subtree\nusing libgit2 but I want to make sure that that isn't wasted work. It\nappears to be exactly what I need to code bits of git-subtree natively.\n\nThoughts?\n\n -Dave\n"},{"id":"197832","messageId":"5038A148.4020003@op5.se","threadId":"31346","inReplyTo":"87a9xkqtfg.fsf@waller.obbligato.org","subject":"Re: libgit2 status","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-08-25T09:56:24Z","receivedAt":"2012-08-25T09:56:24Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 08/24/2012 04:02 PM, greened@obbligato.org wrote:\n> What is the status of libgit2 WRT the overall git project? I recall\n> that there was some discussion of basing bits of git on libgit2 once it\n> matures.\n> \n> I ask because I'm starting a project to improve the abysmal speed of\n> git-subtree split. It's unbearably slow at the moment and as far as I\n> can puzzle out it's due almost entirely to repeated subshell invocations\n> to run git commands.\n> \n> I was planning on doing some experiments rewriting bits of git-subtree\n> using libgit2 but I want to make sure that that isn't wasted work. It\n> appears to be exactly what I need to code bits of git-subtree natively.\n> \n> Thoughts?\n> \n\nlibgit2 is now maintained by Vicent Marti, who was once a gsoc student.\nHe's employed by github and seems to spend most of his time working on\nlibgit2.\n\nPolitically, I'm not sure how keen the git community is on handing\nover control to the core stuff of git to a commercial entity, but it\ndoesn't seem to be a dying project, so I'd say go ahead and do it.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"197849","messageId":"CAFFjANSDyREbNH1qRgYRPw1C87+D=Ft+ZirLvNihkj3UxF-=Eg@mail.gmail.com","threadId":"31346","inReplyTo":"5038A148.4020003@op5.se","subject":"Re: libgit2 status","fromName":"Vicent Marti","fromEmail":"vicent@github.com","sentAt":"2012-08-25T20:46:50Z","receivedAt":"2012-08-25T20:46:50Z","isPatch":false,"sender":{"key":"vicent@github.com","avatar":"https://gravatar.com/avatar/9d57a2b1e3137bf84342ac1dfdf1cde409b86e8fda5397d05f40f17fa5b84a63?d=mp&s=160"},"body":"On Sat, Aug 25, 2012 at 2:56 AM, Andreas Ericsson wrote:\n> Politically, I'm not sure how keen the git community is on handing\n> over control to the core stuff of git to a commercial entity,\n\nThe development of libgit2 happens 100% in the open. I don't know what\n\"commercial entity\" are you talking about, but there are several\ncompanies and independent contributors working on the Library at the\nmoment.\n"},{"id":"197850","messageId":"20120825214614.GA8697@vidovic","threadId":"31346","inReplyTo":"CAFFjANSDyREbNH1qRgYRPw1C87+D=Ft+ZirLvNihkj3UxF-=Eg@mail.gmail.com","subject":"Re: libgit2 status","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2012-08-25T21:46:15Z","receivedAt":"2012-08-25T21:46:15Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 25/08/12, Vicent Marti wrote:\n\n> The development of libgit2 happens 100% in the open. I don't know what\n> \"commercial entity\" are you talking about, but there are several\n> companies and independent contributors working on the Library at the\n> moment.\n\nRight but as far as I'm aware of Junio had reserves about libgit2\nintegration into git due to issues making repositories broken. Though,\nhaving libgit2 as git core would make libgit2 the the-facto standard\nwhich would a *very* big plus.\n\nAlso, I guess that integration into git would mean more developers\ncontibuting for libgit2. Currently, issues seems to be a blocker for\nintegration. So, libgit2 might appear to be a marginal/risky alternative\nfor a long time which is sad.\n\n[ I'm somewhat in the same situation of OP. ]\n\n-- \nNicolas Sebrecht\n"},{"id":"197851","messageId":"87y5l2eh6k.fsf@centaur.cmartin.tk","threadId":"31346","inReplyTo":"20120825214614.GA8697@vidovic","subject":"Re: libgit2 status","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2012-08-25T22:32:35Z","receivedAt":"2012-08-25T22:32:35Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"Nicolas Sebrecht writes:\n\n> The 25/08/12, Vicent Marti wrote:\n>\n>> The development of libgit2 happens 100% in the open. I don't know what\n>> \"commercial entity\" are you talking about, but there are several\n>> companies and independent contributors working on the Library at the\n>> moment.\n>\n> Right but as far as I'm aware of Junio had reserves about libgit2\n> integration into git due to issues making repositories broken. Though,\n\nThe comment I saw about that was that at one point libgit2 had produced\nbroken trees; which is true, the algorithm for the almost-alphanumeric\nsorting was slightly broken. This was fixed quite some time ago, which\nhe also mentioned in the same message.\n\n> [ I'm somewhat in the same situation of OP. ]\n\nIf you wait for it to be perfect, it's never going to happen. If your\napplication would benefit, port it to libgit2 and report the issues you\nfind. That's the only way we can know of the odd edge cases and\nimprovements that we should make.\n\nNote that the GitHub apps for Mac and Windows both use the Library to\nperform parts of their job. Their new backend for the website is also\n(going to be) based on libgit2.\n\nI am also working on a project for a client involving the Library for\nimporting data and the only problem we've had is that we discovered an\nedge case regarding symlinks and an assumption that one of the bindings\nmade wrt diffs, which is getting fixed.\n\n cmn\n"},{"id":"197855","messageId":"CA+EOSBmgsgFz0fMxnOQm10j0cLQ68K4vZr6ZKdjtrtJQDeFYCA@mail.gmail.com","threadId":"31346","inReplyTo":"20120825214614.GA8697@vidovic","subject":"Re: libgit2 status","fromName":"Elia Pinto","fromEmail":"gitter.spiros@gmail.com","sentAt":"2012-08-26T07:26:14Z","receivedAt":"2012-08-26T07:26:14Z","isPatch":false,"sender":{"key":"gitter.spiros@gmail.com","avatar":"https://avatars.githubusercontent.com/u/158490?v=4"},"body":"I know julio notes about libgit2. Anyway the rpm5 mantainer had\ndecided to integrate libgit2 recently. Jfi.\n\nRegards\n\n2012/8/25, Nicolas Sebrecht :\n> The 25/08/12, Vicent Marti wrote:\n>\n>> The development of libgit2 happens 100% in the open. I don't know what\n>> \"commercial entity\" are you talking about, but there are several\n>> companies and independent contributors working on the Library at the\n>> moment.\n>\n> Right but as far as I'm aware of Junio had reserves about libgit2\n> integration into git due to issues making repositories broken. Though,\n> having libgit2 as git core would make libgit2 the the-facto standard\n> which would a *very* big plus.\n>\n> Also, I guess that integration into git would mean more developers\n> contibuting for libgit2. Currently, issues seems to be a blocker for\n> integration. So, libgit2 might appear to be a marginal/risky alternative\n> for a long time which is sad.\n>\n> [ I'm somewhat in the same situation of OP. ]\n>\n> --\n> Nicolas Sebrecht\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n-- \nInviato dal mio dispositivo mobile\n"},{"id":"197867","messageId":"7vharpv77n.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"5038A148.4020003@op5.se","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-26T18:28:12Z","receivedAt":"2012-08-26T18:28:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Politically, I'm not sure how keen the git community is on handing\n> over control to the core stuff of git to a commercial entity, but it\n> doesn't seem to be a dying project, so I'd say go ahead and do it.\n\nI do not think commercial-ness of any entity comes into the picture.\n\nThe only three things that matter are license compatibility (I think\nlibgit2 licensed under GPLv2 + linkage exception is doing just fine\nin that department), maturity and quality of it (it is in early\ndevelopment phase), and the openness of the development process (it\ncould do better by finding ways to better interact with the\nmainstream git development discussion that happens here in the\nlonger term).\n\nAnd the last one should really be a \"longer term\" item. It is more\nimportant for its codebase to get mature and robust, and that can\nonly happen by various projects and products (e.g. GitHub for Mac)\nusing it to improve it. I do not think \"subtree\" (or anything in\ncontrib/ for that matter) is part of \"the core stuff of git\", and do\nnot see a problem; such a move may help both subtree and libgit2.\n\nOver a much longer timeperiod, I wouldn't be surprised if some \"core\nstuff\" gets reimplemented on top of libgit2 and distributed as part\nof the git-core.\n\nThere will be substantial integration and logistics hassles ahead of\nus before that can happen, though. E.g. we could point at libgit2\nas our submodule, but that is not the only way to make git depend on\nlibgit2; it could just be a Build-Depends like we depend on libz.\nLooking at the build dependency of libgit2 itself, I do not think\ntighter integration of the libgit2 itself into the git-core is not\nlikely to happen very soon, and also is not necessarily a good thing\nto do.\n"},{"id":"197873","messageId":"7vvcg5trcf.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"7vharpv77n.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-26T18:56:16Z","receivedAt":"2012-08-26T18:56:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Looking at the build dependency of libgit2 itself, I do not think\n> tighter integration of the libgit2 itself into the git-core is not\n> likely to happen very soon, and also is not necessarily a good thing\n> to do.\n\nObviously I meant \"I think it is not likely to happen and is not\nnecessaryly a good thing\". Dumb double-negatives.\n"},{"id":"197915","messageId":"nnglih0jotj.fsf@transit.us.cray.com","threadId":"31346","inReplyTo":"7vharpv77n.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"","fromEmail":"dag@cray.com","sentAt":"2012-08-27T16:13:12Z","receivedAt":"2012-08-27T16:13:12Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"Junio C Hamano writes:\n\n> And the last one should really be a \"longer term\" item. It is more\n> important for its codebase to get mature and robust, and that can\n> only happen by various projects and products (e.g. GitHub for Mac)\n> using it to improve it. I do not think \"subtree\" (or anything in\n> contrib/ for that matter) is part of \"the core stuff of git\", and do\n> not see a problem; such a move may help both subtree and libgit2.\n>\n> Over a much longer timeperiod, I wouldn't be surprised if some \"core\n> stuff\" gets reimplemented on top of libgit2 and distributed as part\n> of the git-core.\n\nI am hoping to move git-subtree into core once it performs a little\nbetter and I've fixed a couple of bugs. Will basing it on libgit2 delay\nthat process significantly? Six months delay is no problem. 2 years\nwould be problematic.\n\nI would be happy to be a guinea pig for libgit2 in order to improve it,\nbut I don't want to significantly impact git-subtree's move to core.\nI'll have to figure out the right balance there given feedback.\n\n -Dave\n"},{"id":"197920","messageId":"7vfw78s1kd.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"nnglih0jotj.fsf@transit.us.cray.com","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-27T17:10:42Z","receivedAt":"2012-08-27T17:10:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n> I am hoping to move git-subtree into core once it performs a little\n> better and I've fixed a couple of bugs. Will basing it on libgit2 delay\n> that process significantly? Six months delay is no problem. 2 years\n> would be problematic.\n>\n> I would be happy to be a guinea pig for libgit2 in order to improve it,\n> but I don't want to significantly impact git-subtree's move to core.\n> I'll have to figure out the right balance there given feedback.\n\nI expect it will take some time for libgit2 to allow our Makefile to\nstart saying \"LDFLAGS += -libgit2\"; it will need to become as stable\nand widespread as other libraries we depend on, e.g. -lz and -lcurl.\n"},{"id":"197928","messageId":"nngsjb8i30w.fsf@transit.us.cray.com","threadId":"31346","inReplyTo":"7vfw78s1kd.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"","fromEmail":"dag@cray.com","sentAt":"2012-08-27T18:49:19Z","receivedAt":"2012-08-27T18:49:19Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"Junio C Hamano writes:\n\n>> I would be happy to be a guinea pig for libgit2 in order to improve it,\n>> but I don't want to significantly impact git-subtree's move to core.\n>> I'll have to figure out the right balance there given feedback.\n>\n> I expect it will take some time for libgit2 to allow our Makefile to\n> start saying \"LDFLAGS += -libgit2\"; it will need to become as stable\n> and widespread as other libraries we depend on, e.g. -lz and -lcurl.\n\nWell that's a chicken-and-egg problem, isn't it. How will a library\nbecome widespread unless something uses it?\n\nWould it be enough to have libgit2 as an installable package in the\nmajor distributions?\n\n -Dave\n"},{"id":"197931","messageId":"7v6284qfw8.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"nngsjb8i30w.fsf@transit.us.cray.com","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-27T19:44:07Z","receivedAt":"2012-08-27T19:44:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n> Junio C Hamano writes:\n>\n>>> I would be happy to be a guinea pig for libgit2 in order to improve it,\n>>> but I don't want to significantly impact git-subtree's move to core.\n>>> I'll have to figure out the right balance there given feedback.\n>>\n>> I expect it will take some time for libgit2 to allow our Makefile to\n>> start saying \"LDFLAGS += -libgit2\"; it will need to become as stable\n>> and widespread as other libraries we depend on, e.g. -lz and -lcurl.\n>\n> Well that's a chicken-and-egg problem, isn't it. How will a library\n> become widespread unless something uses it?\n\nThat something will not be the git core itself. Otherwise we will\nlose a stable reference implementation to catch its bugs.\n"},{"id":"197933","messageId":"nng4nnohvyk.fsf@transit.us.cray.com","threadId":"31346","inReplyTo":"7v6284qfw8.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"","fromEmail":"dag@cray.com","sentAt":"2012-08-27T21:21:55Z","receivedAt":"2012-08-27T21:21:55Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"Junio C Hamano writes:\n\n>> Well that's a chicken-and-egg problem, isn't it. How will a library\n>> become widespread unless something uses it?\n>\n> That something will not be the git core itself. Otherwise we will\n> lose a stable reference implementation to catch its bugs.\n\nWell, the whole question here is whether git-subtree can become part of\ncore if it is based on libgit2. It boils down to what you mean by\n\"widespread,\" I guess. Does \"widespread\" mean \"available as a package\nin major distributions,\" \"installed by default in major distributions\"\nor something else?\n\n -Dave\n"},{"id":"197936","messageId":"20120827214027.GA511@vidovic","threadId":"31346","inReplyTo":"7v6284qfw8.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2012-08-27T21:40:27Z","receivedAt":"2012-08-27T21:40:27Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 27/08/12, Junio C Hamano wrote:\n> writes:\n> \n> > Junio C Hamano writes:\n> >\n> >>> I would be happy to be a guinea pig for libgit2 in order to improve it,\n> >>> but I don't want to significantly impact git-subtree's move to core.\n> >>> I'll have to figure out the right balance there given feedback.\n> >>\n> >> I expect it will take some time for libgit2 to allow our Makefile to\n> >> start saying \"LDFLAGS += -libgit2\"; it will need to become as stable\n> >> and widespread as other libraries we depend on, e.g. -lz and -lcurl.\n> >\n> > Well that's a chicken-and-egg problem, isn't it. How will a library\n> > become widespread unless something uses it?\n> \n> That something will not be the git core itself. Otherwise we will\n> lose a stable reference implementation to catch its bugs.\n\nThis is exactly what I'm most afraid about. I tend to think it's a\nchicken-and-egg problem, too.\n\nDo you expect one big merge of a very stable libgit2 at some point?\nBecause, asking others to implement widely used tools on top of libgit2\nin order to have it as stable/tested as curl is not going to happen, IMHO.\n\nOtherwise, what about going with this optionnal \"LDFLAGS += -libgit2\"\nASAP with good disclaimer that it's only intended for development and\ntesting purpose? Then, git-core could slowly rely on functions of\nlibgit2, one after the other.\n\n\n-- \nNicolas Sebrecht\n"},{"id":"197998","messageId":"nngr4qqhp7x.fsf@transit.us.cray.com","threadId":"31346","inReplyTo":"20120827214027.GA511@vidovic","subject":"Re: libgit2 status","fromName":"","fromEmail":"dag@cray.com","sentAt":"2012-08-28T17:59:46Z","receivedAt":"2012-08-28T17:59:46Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"Nicolas Sebrecht writes:\n\n> Do you expect one big merge of a very stable libgit2 at some point?\n\nI don't think there's any need to merge libgit2 into the git project\nsource. As a library, it should be perfectly usable as a project of its\nown, just like libcurl and libz.\n\n> Otherwise, what about going with this optionnal \"LDFLAGS += -libgit2\"\n> ASAP with good disclaimer that it's only intended for development and\n> testing purpose? Then, git-core could slowly rely on functions of\n> libgit2, one after the other.\n\nThis makes a lot of sense to me.\n\n -David\n"},{"id":"198009","messageId":"7vvcg2zwvq.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"nngr4qqhp7x.fsf@transit.us.cray.com","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-28T18:36:57Z","receivedAt":"2012-08-28T18:36:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n> Nicolas Sebrecht writes:\n>\n>> Do you expect one big merge of a very stable libgit2 at some point?\n>\n> I don't think there's any need to merge libgit2 into the git project\n> source. As a library, it should be perfectly usable as a project of its\n> own, just like libcurl and libz.\n>\n>> Otherwise, what about going with this optionnal \"LDFLAGS += -libgit2\"\n>> ASAP with good disclaimer that it's only intended for development and\n>> testing purpose? Then, git-core could slowly rely on functions of\n>> libgit2, one after the other.\n>\n> This makes a lot of sense to me.\n\nAs I already said in my earlier message in $gmane/204305, I wouldn't\nbe surprised if some \"core stuff\" gets reimplemented on top of\nlibgit2 and distributed as part of the git-core. But at this\nmoment, I see that just as a blip of possibility far in the future.\n\nIt would most likely start slowly, by adding lg-client/cat-file.c\nthat is linked with libgit2 when \"make USE_LIBGIT2=YesPlease\" was\nasked for, and we compile the tried-and-true builtin/cat-file.c\notherwise (\"cat-file\" may actually not the most trivial first step,\nthough, but I think readers get the idea).\n\nEven after most if not all commands have counterparts reimplemented\non libgit2, I do not think we can afford to drop any of the original\nfor a long time. For that to happen, at the very least:\n\n - libgit2 must be available in major distros so that people can say\n \"[yum|apt-get] install libgit2-dev\"; and\n\n - the version of it packaged for major distros are recent and\n stable enough, so that we never have to say \"distro X ships with\n libgit2 that is too old, so people on that distro have to compile\n it from the source.\"\n\nwhich is the quality we expect from libraries we would depend on,\nlike -lz, -lcurl, etc.\n\nIt is OK if we have to conditionally compile out some of our code in\nthe periphery when libgit2 that is available on the platform is too\nold (we allow it for -lcurl already).\n\nBut all of the above assumes one thing: the reimplementated result\ndoes not suck ;-) which is a large unknown.\n"},{"id":"201542","messageId":"CACnwZYe6BZVuqCCPho5+3dy=rzKqDv1A8uGAvhLm2JPO9b2LMw@mail.gmail.com","threadId":"31346","inReplyTo":"7vvcg2zwvq.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2012-10-19T00:42:56Z","receivedAt":"2012-10-19T00:42:56Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"Just an addendum, the libfication would come from within the core git\ndevelopers, i.e, they start making the git library inside git itself.\nThe git project would provide the API, not an external project.\n\nWith some structure like:\n\ninclude/git.h\nsrc/git.c\n\n...\n\nwhatever.\n\nAnd doing the way Jeff did with argv_array for example and with rigid\nstyle guide defining how new APIs should be written. Just my 2 cents.\nDon't take it to seriously.\n"},{"id":"201545","messageId":"CALkWK0=P7THaJduYFS1Sr6mxtNqAWQsDgwQyr_KEX4NA4kmVSA@mail.gmail.com","threadId":"31346","inReplyTo":"CACnwZYe6BZVuqCCPho5+3dy=rzKqDv1A8uGAvhLm2JPO9b2LMw@mail.gmail.com","subject":"Re: libgit2 status","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2012-10-19T03:54:21Z","receivedAt":"2012-10-19T03:54:21Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thiago Farina wrote:\n> [...]\n> With some structure like:\n>\n> include/git.h\n> src/git.c\n>\n> ...\n>\n> whatever.\n> [...]\n\nJunio- is it reasonable to expect the directory-restructuring by 2.0?\n\nRam\n"},{"id":"201565","messageId":"7vvce6i5j2.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"CALkWK0=P7THaJduYFS1Sr6mxtNqAWQsDgwQyr_KEX4NA4kmVSA@mail.gmail.com","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-19T20:13:53Z","receivedAt":"2012-10-19T20:13:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Thiago Farina wrote:\n>> [...]\n>> With some structure like:\n>>\n>> include/git.h\n>> src/git.c\n>>\n>> ...\n>>\n>> whatever.\n>> [...]\n>\n> Junio- is it reasonable to expect the directory-restructuring by 2.0?\n\nI actually hate \"include/git.h vs src/git.c\"; you have distinction\nbetween .c and .h already.\n"},{"id":"201580","messageId":"nngobjyf6xd.fsf@transit.us.cray.com","threadId":"31346","inReplyTo":"7vvce6i5j2.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"","fromEmail":"dag@cray.com","sentAt":"2012-10-19T22:11:58Z","receivedAt":"2012-10-19T22:11:58Z","isPatch":false,"sender":{"key":"dag@cray.com","avatar":null},"body":"Junio C Hamano writes:\n\n> I actually hate \"include/git.h vs src/git.c\"; you have distinction\n> between .c and .h already.\n\n+1\n\n -David\n"},{"id":"201582","messageId":"7v4nlqhymd.fsf@alter.siamese.dyndns.org","threadId":"31346","inReplyTo":"7vvce6i5j2.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-19T22:43:06Z","receivedAt":"2012-10-19T22:43:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Ramkumar Ramachandra writes:\n>\n>> Thiago Farina wrote:\n>>> [...]\n>>> With some structure like:\n>>>\n>>> include/git.h\n>>> src/git.c\n>>>\n>>> ...\n>>>\n>>> whatever.\n>>> [...]\n>>\n>> Junio- is it reasonable to expect the directory-restructuring by 2.0?\n>\n> I actually hate \"include/git.h vs src/git.c\"; you have distinction\n> between .c and .h already.\n\nHaving said that, I do not mind moving codeblocks around to make\nsome files purely library-ish while others purely commands.\n\nIdeally, if you run\n\n $ nm --defined-only -g builtin/frotz.o\n\nyou should see nothing but \"T cmd_frotz\" (there are exceptions, most\nnotably, what the commands in the \"log\" family do are so close with\neach other that builtin/log.o can define cmd_* for all of them).\n\n $ nm --defined-only -og builtin/*.o | grep -v 'T cmd_'\n\na handful of offenders. If these functions with external linkage\nare truly useful across subcommands, we should move them to a more\nlibrary-ish location.\n\nIt may require splitting the bits that are too closely tied to the\nexternal interface they are implementing from these functions,\ngeneralizing only the core-ish logic from them, and moving them to a\nmore library-ish file as a preparatory step. Such a library-ish file\nmay be created inside lib/ subdirectory from the get-go.\n\nUntil that kind of code restructure happens, I do not see much sense\nin just moving files, e.g. renaming revision.c to src/revision.c or\nlib/revision.c or somesuch.\n"},{"id":"201585","messageId":"CACnwZYdiz05xRr5b+Hn0o-wZRm+cOJ3hQ8LGiABm8G10Pos10A@mail.gmail.com","threadId":"31346","inReplyTo":"7vvce6i5j2.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2012-10-20T01:21:30Z","receivedAt":"2012-10-20T01:21:30Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"On Fri, Oct 19, 2012 at 5:13 PM, Junio C Hamano wrote:\n> I actually hate \"include/git.h vs src/git.c\"; you have distinction\n> between .c and .h already.\nWhich distinction are you talking about? This is not an issue of\nheader file versus source file, but a public header file to be\nincluded by external projects versus internal header files that are\nintended to be included only by git itself and that will probably live\nunder src/ directory.\n"},{"id":"201588","messageId":"50825999.5080208@op5.se","threadId":"31346","inReplyTo":"7vvce6i5j2.fsf@alter.siamese.dyndns.org","subject":"Re: libgit2 status","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-10-20T07:58:17Z","receivedAt":"2012-10-20T07:58:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 10/19/2012 10:13 PM, Junio C Hamano wrote:\n> Ramkumar Ramachandra writes:\n> \n>> Thiago Farina wrote:\n>>> [...]\n>>> With some structure like:\n>>>\n>>> include/git.h\n>>> src/git.c\n>>>\n>>> ...\n>>>\n>>> whatever.\n>>> [...]\n>>\n>> Junio- is it reasonable to expect the directory-restructuring by 2.0?\n> \n> I actually hate \"include/git.h vs src/git.c\"; you have distinction\n> between .c and .h already.\n> \n\nAgreed. The way libgit2 does it is to have \"src/tag.[ch]\", which are\nfor internal use, and then \"src/include/tag.h\" which is the published\nversion that others can use to write code against the tag library.\nsrc/tag.h always includes src/include/tag.h, so no code needs to be\nduplicated, but internal parts of the library can still use lower-\nlevel stuff if it wants to. It's a good compromise when creating a\nlibrary from application code and there were no opaque types from\nthe start.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"}]}