{"thread":{"id":"14773","subject":"linking libgit.a in C++ projects","startedAt":"2008-07-31T09:53:37Z","lastAt":"2008-08-04T14:52:07Z","messageCount":26,"participants":["cte","Dmitry Potapov","Petr Baudis","Pedro Melo","Boaz Harrosh","Sverre Rabbelier","Alex Riesen","Avery Pennarun","Shawn O. Pearce","Linus Torvalds","Steve Frécinaux"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"85752","messageId":"ac9f0f090807310253v1d97e2a1n4ddf34aa4fdc79f0@mail.gmail.com","threadId":"14773","inReplyTo":null,"subject":"linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-07-31T09:53:37Z","receivedAt":"2008-07-31T09:53:37Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"I'm writing a git gui for OS X using cocoa/Objective-C++, and rather\nthan being lame and parsing the output the various git commands, I'm\nusing libgit.a to provide all of the needed functionality for my app.\nHowever, the git source uses a few reserved C++ keywords; namely\n'typename', and 'new'. So, I was wondering if it is worth submitting a\npatch to fix these issues... I'm asking because I'm new to the whole\nopen source thing, and I don't want to get yelled at by the git\nmaintainers for submitting stupid patches that no one in their right\nmind would accept :)\n\nThanks!\n"},{"id":"85757","messageId":"20080731105727.GF7008@dpotapov.dyndns.org","threadId":"14773","inReplyTo":"ac9f0f090807310253v1d97e2a1n4ddf34aa4fdc79f0@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-31T10:57:27Z","receivedAt":"2008-07-31T10:57:27Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:\n> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather\n> than being lame and parsing the output the various git commands, I'm\n> using libgit.a to provide all of the needed functionality for my app.\n\nDon't do that! libgit.a is an internal library used solely to build\ngit binaries. It means that its interface can be cahnged at any time.\nThough, there is an idea of creating the real git library that other\napplications can use, but AFAIK no one is working on it. So parsing\noutput is the only correct solution right now. In fact, it is not\ndifficult to do, because most plumbing commands are rather flexibly\nin what they output and how.\n\n> However, the git source uses a few reserved C++ keywords; namely\n> 'typename', and 'new'.\n\nBecause this source code are meant to be compiled by C and not by C++!\nEven if we will have real git library for other applications to use,\nit still be compiled only by C. Thus, C++ keywords are not issue.\n\nDmitry\n"},{"id":"85760","messageId":"ac9f0f090807310410u461f5584ved74769d8452c539@mail.gmail.com","threadId":"14773","inReplyTo":"20080731105727.GF7008@dpotapov.dyndns.org","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-07-31T11:10:47Z","receivedAt":"2008-07-31T11:10:47Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"On Thu, Jul 31, 2008 at 3:57 AM, Dmitry Potapov wrote:\n> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:\n>> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather\n>> than being lame and parsing the output the various git commands, I'm\n>> using libgit.a to provide all of the needed functionality for my app.\n>\n> Don't do that! libgit.a is an internal library used solely to build\n> git binaries. It means that its interface can be cahnged at any time.\n> Though, there is an idea of creating the real git library that other\n> applications can use, but AFAIK no one is working on it. So parsing\n> output is the only correct solution right now. In fact, it is not\n> difficult to do, because most plumbing commands are rather flexibly\n> in what they output and how.\n\nI'm not worried about the interfaces changing; the gui is tied to a\nparticular version of git, and I will update the code that calls into\nlibgit I pull new changes from the mainline into my local clone. Also,\nwho's to say that the output of the various commands won't change\nformats with future releases of git? There is no correct solution if\nyou are worried about forward compatibility, unless a well defined API\nis created (which would be sweet btw, but is probably not a priority).\n\n>> However, the git source uses a few reserved C++ keywords; namely\n>> 'typename', and 'new'.\n>\n> Because this source code are meant to be compiled by C and not by C++!\n> Even if we will have real git library for other applications to use,\n> it still be compiled only by C. Thus, C++ keywords are not issue.\n\nClearly ;)\n\nFortunately, g++ can compile C programs and link static libraries that\nwere compiled by C compilers, unless of course, they use C++ keywords.\nI don't think it is unreasonable to rename the _very few_ C++ keywords\nin git's source in the interest of allowing C++ projects to leverage\nlibgit.\n"},{"id":"85761","messageId":"20080731111446.GO32184@machine.or.cz","threadId":"14773","inReplyTo":"20080731105727.GF7008@dpotapov.dyndns.org","subject":"Re: linking libgit.a in C++ projects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-31T11:14:46Z","receivedAt":"2008-07-31T11:14:46Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Jul 31, 2008 at 02:57:27PM +0400, Dmitry Potapov wrote:\n> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:\n> > I'm writing a git gui for OS X using cocoa/Objective-C++, and rather\n> > than being lame and parsing the output the various git commands, I'm\n> > using libgit.a to provide all of the needed functionality for my app.\n> \n> Don't do that! libgit.a is an internal library used solely to build\n> git binaries. It means that its interface can be cahnged at any time.\n\nI don't think this is that big a problem; there are applications that\nare doing this already, e.g. cgit, and if you tie your application to\na particular git version by for example making git a submodule of your\nsource, this is pretty safe; it will just mean that you will have to\ndo some non-trivial porting of your code to the new interface each time\nyou update - but I think large changes in the interface are pretty rare\nin practice by now, and there shouldn't be much on the horizon either(?).\n\n> > However, the git source uses a few reserved C++ keywords; namely\n> > 'typename', and 'new'.\n> \n> Because this source code are meant to be compiled by C and not by C++!\n> Even if we will have real git library for other applications to use,\n> it still be compiled only by C. Thus, C++ keywords are not issue.\n\nWhat would be the reason to disallow C++ users? The costs aren't that\nhigh, and (modulo, say, extern \"C\" { }) there should be no C-C++\ncompatibility issues, right?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nAs in certain cults it is possible to kill a process if you know\nits true name. -- Ken Thompson and Dennis M. Ritchie\n"},{"id":"85762","messageId":"0EC13CCC-0F7B-41A0-BEB2-67E6EC8D5E37@simplicidade.org","threadId":"14773","inReplyTo":"ac9f0f090807310410u461f5584ved74769d8452c539@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Pedro Melo","fromEmail":"melo@simplicidade.org","sentAt":"2008-07-31T11:16:45Z","receivedAt":"2008-07-31T11:16:45Z","isPatch":false,"sender":{"key":"melo@simplicidade.org","avatar":"https://gravatar.com/avatar/13ddbb01e300285a93aa1e3739653a81f9b1d3438bd03a4ac36b88e4ffeeafc3?d=mp&s=160"},"body":"\nOn Jul 31, 2008, at 12:10 PM, cte wrote:\n> On Thu, Jul 31, 2008 at 3:57 AM, Dmitry Potapov \n> wrote:\n>> On Thu, Jul 31, 2008 at 02:53:37AM -0700, cte wrote:\n>>> However, the git source uses a few reserved C++ keywords; namely\n>>> 'typename', and 'new'.\n>>\n>> Because this source code are meant to be compiled by C and not by C+ \n>> +!\n>> Even if we will have real git library for other applications to use,\n>> it still be compiled only by C. Thus, C++ keywords are not issue.\n>\n[...]\n> Fortunately, g++ can compile C programs and link static libraries that\n> were compiled by C compilers, unless of course, they use C++ keywords.\n> I don't think it is unreasonable to rename the _very few_ C++ keywords\n> in git's source in the interest of allowing C++ projects to leverage\n> libgit.\n\nI think the point Dmitry was trying to make is that you should compile \nlibgit as C, using gcc, and then link it with your C++/Objective C code.\n\nNo patch is required to git, only to your makefile/xcode project file.\n\nBest regards,\n-- \nPedro Melo\nBlog: http://www.simplicidade.org/notes/\nXMPP ID: melo@simplicidade.org\nUse XMPP!\n"},{"id":"85763","messageId":"ac9f0f090807310418r109b76bdq37cdfd0adc81f74d@mail.gmail.com","threadId":"14773","inReplyTo":"20080731111446.GO32184@machine.or.cz","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-07-31T11:18:08Z","receivedAt":"2008-07-31T11:18:08Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"> What would be the reason to disallow C++ users? The costs aren't that\n> high, and (modulo, say, extern \"C\" { }) there should be no C-C++\n> compatibility issues, right?\n\nExactly. It works just great for me in XCode 3.1 on OS X.\n"},{"id":"85764","messageId":"20080731112037.GP32184@machine.or.cz","threadId":"14773","inReplyTo":"0EC13CCC-0F7B-41A0-BEB2-67E6EC8D5E37@simplicidade.org","subject":"Re: linking libgit.a in C++ projects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-31T11:20:37Z","receivedAt":"2008-07-31T11:20:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Jul 31, 2008 at 12:16:45PM +0100, Pedro Melo wrote:\n> I think the point Dmitry was trying to make is that you should compile \n> libgit as C, using gcc, and then link it with your C++/Objective C code.\n>\n> No patch is required to git, only to your makefile/xcode project file.\n\nlibgit has a certain (albeit currently unofficial and non-settled) API\nand the API is defined in header files that must be eatable by C++\ncompilers in order to do this.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"85765","messageId":"ac9f0f090807310420y23150005jbd0bcaec061301c4@mail.gmail.com","threadId":"14773","inReplyTo":"0EC13CCC-0F7B-41A0-BEB2-67E6EC8D5E37@simplicidade.org","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-07-31T11:20:44Z","receivedAt":"2008-07-31T11:20:44Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":">> Fortunately, g++ can compile C programs and link static libraries that\n>> were compiled by C compilers, unless of course, they use C++ keywords.\n>> I don't think it is unreasonable to rename the _very few_ C++ keywords\n>> in git's source in the interest of allowing C++ projects to leverage\n>> libgit.\n>\n> I think the point Dmitry was trying to make is that you should compile\n> libgit as C, using gcc, and then link it with your C++/Objective C code.\n>\n> No patch is required to git, only to your makefile/xcode project file.\n\nThe git .h files must be in your include path, and must not contain\nC++ keywords in order to link against libgit.a.\n"},{"id":"85768","messageId":"20080731123406.GG7008@dpotapov.dyndns.org","threadId":"14773","inReplyTo":"20080731111446.GO32184@machine.or.cz","subject":"Re: linking libgit.a in C++ projects","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-31T12:34:06Z","receivedAt":"2008-07-31T12:34:06Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 31, 2008 at 01:14:46PM +0200, Petr Baudis wrote:\n> \n> I don't think this is that big a problem; there are applications that\n> are doing this already, e.g. cgit, and if you tie your application to\n> a particular git version by for example making git a submodule of your\n> source, this is pretty safe; it will just mean that you will have to\n> do some non-trivial porting of your code to the new interface each time\n> you update - but I think large changes in the interface are pretty rare\n> in practice by now, and there shouldn't be much on the horizon either(?).\n\nWhat you see as large changes depend on how well you know git internals.\nGit develops very quickly and if someone who is trying to use libgit.a\ndoes not follow git development closely, it may happen pretty soon that\neven not so big changes will become a huge problem to accomadate them.\nAs result, the program may stick with an old Git version, and that puts\nusers of this program in the situation where they cannot use their\nfavorite frontend with new repositories.\n\n> What would be the reason to disallow C++ users? The costs aren't that\n> high, and (modulo, say, extern \"C\" { }) there should be no C-C++\n> compatibility issues, right?\n\nI mean that putting extern \"C\" { } around should be sufficient to use\nthis library in C++. But I see now some current headers contains some\nC++ keywords and that causes the problem. So, yes, those headers should\nbe corrected if they become part of external available API. I am not\nsure whether it makes sense to correct them now, but there are only\nthree places where C++ keywords are used:\n\ndiff.h:135:extern int diff_tree_sha1(const unsigned char *old, const\ndiff.h:137:extern int diff_root_tree_sha1(const unsigned char *new,\nobject.h:38:extern const char *typename(unsigned int type);\n\nSo, the patch should not be large, and it is up to Junio to decide\nwhat to do about it.\n\nDmitry\n"},{"id":"85777","messageId":"4891B872.3040707@panasas.com","threadId":"14773","inReplyTo":"ac9f0f090807310253v1d97e2a1n4ddf34aa4fdc79f0@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Boaz Harrosh","fromEmail":"bharrosh@panasas.com","sentAt":"2008-07-31T13:04:50Z","receivedAt":"2008-07-31T13:04:50Z","isPatch":false,"sender":{"key":"bharrosh@panasas.com","avatar":"https://gravatar.com/avatar/347e426f8ca0409f6891ceeefd4c3c2d8769608382323057efeaa362b4c3dbf3?d=mp&s=160"},"body":"cte wrote:\n> I'm writing a git gui for OS X using cocoa/Objective-C++, and rather\n> than being lame and parsing the output the various git commands, I'm\n> using libgit.a to provide all of the needed functionality for my app.\n> However, the git source uses a few reserved C++ keywords; namely\n> 'typename', and 'new'. So, I was wondering if it is worth submitting a\n> patch to fix these issues... I'm asking because I'm new to the whole\n> open source thing, and I don't want to get yelled at by the git\n> maintainers for submitting stupid patches that no one in their right\n> mind would accept :)\n> \n> Thanks!\n> --\n\nThe practice of avoiding C++ keywords from public C headers is\nvery welcome. You should send a patch and try to push it.\n\nThat said the problem can be easily avoided.\n\nProduce a C file and header that defines some stable API to your\nGUI application, that does not expose any git internal headers.\nThen compile that, say git_api.c, with C compiler in Makefile\nand extern \"C\" link that file to your C++ application. This will\ncompletely insulate you from any git code.\n\nThis could also solve the other problem of API changing, only\nthe git_api.c need change, your outer GUI code stays the same.\n\nAnd if you do all that maybe you can submit it for inclusion\nas a: somewhat stable high-level library, for developers.\nAla git-dev\n\nCheers\nBoaz\n"},{"id":"85783","messageId":"20080731144424.GH7008@dpotapov.dyndns.org","threadId":"14773","inReplyTo":"4891B872.3040707@panasas.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-31T14:44:24Z","receivedAt":"2008-07-31T14:44:24Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 31, 2008 at 04:04:50PM +0300, Boaz Harrosh wrote:\n> \n> Produce a C file and header that defines some stable API to your\n> GUI application, that does not expose any git internal headers.\n> Then compile that, say git_api.c, with C compiler in Makefile\n> and extern \"C\" link that file to your C++ application. This will\n> completely insulate you from any git code.\n\nWhile the idea of creating of such a wrapper makes sense, it may not\neasy to implement properly in all cases, because some git functions\ndo not free allocated memory as they rely on this memory being free\nat exit. There is a problem with die() as it is not enough to longjmp\nfrom it, you have to free all resources that were allocated (such as\nopen files, memory). Thus writing a full functional library, which\nwill not leak resources, is not an easy task. Of course, some of Git\nfunction can be used easily without risk that your application will\nleak resources.\n\nDmitry\n"},{"id":"85790","messageId":"bd6139dc0807311127j57d9ab5ckd6acf16d17621614@mail.gmail.com","threadId":"14773","inReplyTo":"ac9f0f090807310410u461f5584ved74769d8452c539@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-31T18:27:55Z","receivedAt":"2008-07-31T18:27:55Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 13:10, cte wrote:\n> I'm not worried about the interfaces changing; the gui is tied to a\n> particular version of git, and I will update the code that calls into\n> libgit I pull new changes from the mainline into my local clone.\n\nYou should be ;). Unless you are planning to learn a lot of C very\nfast, you should be worried about the interfaces changing. That is, if\nyou want your GUI to be able to stay up to date with the current git\nversion.\n\n> who's to say that the output of the various commands won't change\n> formats with future releases of git?\n\nJunio is to say. Plumbing output format is git's API.\n\n> There is no correct solution if\n> you are worried about forward compatibility, unless a well defined API\n> is created (which would be sweet btw, but is probably not a priority).\n\nThere is, use the plumbing, forward compatibility is 95% assured. With\nthe exception of major releases, for which any plumbing\noutput/behavior changes will be announced in the changelog, usually\nincluding an explanation on how to change your code to match.\n\nIn short, use the forc-... errr, plumbing ;).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85793","messageId":"20080731183732.GA7598@steel.home","threadId":"14773","inReplyTo":"4891B872.3040707@panasas.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-31T18:37:32Z","receivedAt":"2008-07-31T18:37:32Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:\n> Produce a C file and header that defines some stable API to your\n> GUI application, that does not expose any git internal headers.\n> Then compile that, say git_api.c, with C compiler in Makefile\n> and extern \"C\" link that file to your C++ application. This will\n> completely insulate you from any git code.\n\nno, it wont. He still have to resolve name conflicts at the link time.\n"},{"id":"85796","messageId":"32541b130807311155v50ee6ddaha1bba2f56e9bd61d@mail.gmail.com","threadId":"14773","inReplyTo":"20080731183732.GA7598@steel.home","subject":"Re: linking libgit.a in C++ projects","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-31T18:55:26Z","receivedAt":"2008-07-31T18:55:26Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/31/08, Alex Riesen wrote:\n> Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:\n> > Produce a C file and header that defines some stable API to your\n> > GUI application, that does not expose any git internal headers.\n> > Then compile that, say git_api.c, with C compiler in Makefile\n> > and extern \"C\" link that file to your C++ application. This will\n> > completely insulate you from any git code.\n>\n> no, it wont. He still have to resolve name conflicts at the link time.\n\nLanguage keywords (as opposed to function names) like 'new' and\n'typename' are definitely not exported to the object files. Moreover,\nfunction parameter names aren't either.\n\nAvery\n"},{"id":"85830","messageId":"ac9f0f090807311431p3e943441xce8f2ac03ba1700@mail.gmail.com","threadId":"14773","inReplyTo":"4891B872.3040707@panasas.com","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-07-31T21:31:44Z","receivedAt":"2008-07-31T21:31:44Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"Excellent idea; thank you!\n\n> The practice of avoiding C++ keywords from public C headers is\n> very welcome. You should send a patch and try to push it.\n>\n> That said the problem can be easily avoided.\n>\n> Produce a C file and header that defines some stable API to your\n> GUI application, that does not expose any git internal headers.\n> Then compile that, say git_api.c, with C compiler in Makefile\n> and extern \"C\" link that file to your C++ application. This will\n> completely insulate you from any git code.\n>\n> This could also solve the other problem of API changing, only\n> the git_api.c need change, your outer GUI code stays the same.\n>\n> And if you do all that maybe you can submit it for inclusion\n> as a: somewhat stable high-level library, for developers.\n> Ala git-dev\n>\n> Cheers\n> Boaz\n>\n>\n"},{"id":"85832","messageId":"ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com","threadId":"14773","inReplyTo":"bd6139dc0807311127j57d9ab5ckd6acf16d17621614@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-07-31T21:44:42Z","receivedAt":"2008-07-31T21:44:42Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"On Thu, Jul 31, 2008 at 11:27 AM, Sverre Rabbelier wrote:\n> On Thu, Jul 31, 2008 at 13:10, cte wrote:\n>> I'm not worried about the interfaces changing; the gui is tied to a\n>> particular version of git, and I will update the code that calls into\n>> libgit I pull new changes from the mainline into my local clone.\n>\n> You should be ;). Unless you are planning to learn a lot of C very\n> fast, you should be worried about the interfaces changing. That is, if\n> you want your GUI to be able to stay up to date with the current git\n> version.\n\nThat is the plan.\n\n>> who's to say that the output of the various commands won't change\n>> formats with future releases of git?\n>\n> Junio is to say. Plumbing output format is git's API.\n\nUsing output from the command line utilities as an API has its own set\nof problems. For instance, check out some of the difficulties that\ngitk and qgit have had to deal with:\nhttp://kerneltrap.org/mailarchive/git/2007/11/2/379067. Digging into\nthe git internals and reusing its core functions will always be more\npowerful and flexible than parsing command line output. Of course, it\nis not always easy; git wasn't written to be easily compiled into a\nlibrary and reused (graceful error handling and memory management are\nproblematic). But I think the right thing to do is to work towards\nmaking the awesome git internals easier to use for other developers so\ngreat tools can continue to be built on top of git.\n\n>> There is no correct solution if\n>> you are worried about forward compatibility, unless a well defined API\n>> is created (which would be sweet btw, but is probably not a priority).\n>\n> There is, use the plumbing, forward compatibility is 95% assured. With\n> the exception of major releases, for which any plumbing\n> output/behavior changes will be announced in the changelog, usually\n> including an explanation on how to change your code to match.\n\n95% assured != correct, IMO :)\n\n> In short, use the forc-... errr, plumbing ;).\n>\n> --\n> Cheers,\n>\n> Sverre Rabbelier\n>\n"},{"id":"85835","messageId":"bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com","threadId":"14773","inReplyTo":"ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-31T21:51:43Z","receivedAt":"2008-07-31T21:51:43Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 23:44, cte wrote:\n> Using output from the command line utilities as an API has its own set\n> of problems. For instance, check out some of the difficulties that\n> gitk and qgit have had to deal with:\n> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.\n\nI beg to differ. If I skimmed the topic correctly, the problems there\nwere not related to having to parse git's output, but due to the fact\nthat '--topo-order' is a post-processing operation, which takes long.\nDo read the recent discussion between Linus and Roman about that.\n\n> Digging into\n> the git internals and reusing its core functions will always be more\n> powerful and flexible than parsing command line output.\n\nSure, but is it worth it? What do you need in your GUI that you cannot\nget from the plumbing?\n\n> Of course, it\n> is not always easy; git wasn't written to be easily compiled into a\n> library and reused (graceful error handling and memory management are\n> problematic). But I think the right thing to do is to work towards\n> making the awesome git internals easier to use for other developers so\n> great tools can continue to be built on top of git.\n\nI do agree with that, libification of git would be really nice.\nEspecially since that'd mean that integrating it into other languages\n(by means of wrappers), such as Python or Ruby, becomes a lot easier.\n\n>> There is, use the plumbing, forward compatibility is 95% assured. With\n>> the exception of major releases, for which any plumbing\n>> output/behavior changes will be announced in the changelog, usually\n>> including an explanation on how to change your code to match.\n>\n> 95% assured != correct, IMO :)\n\nWhy not? Junio has a very good reputation of keeping git backwards\ncompatible. The 95% is of course not an actual figure but an\nexpression meant to indicate \"statement is true, minus a few rare case\nexceptions\".\n\n>> In short, use the forc-... errr, plumbing ;).\n>>\n>> --\n>> Cheers,\n>>\n>> Sverre Rabbelier\n>>\n\nIt's ok to remove text that you do not respond to, including signatures :P.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85836","messageId":"20080731215818.GD24631@spearce.org","threadId":"14773","inReplyTo":"bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-31T21:58:18Z","receivedAt":"2008-07-31T21:58:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sverre Rabbelier wrote:\n> On Thu, Jul 31, 2008 at 23:44, cte wrote:\n> > Using output from the command line utilities as an API has its own set\n> > of problems. For instance, check out some of the difficulties that\n> > gitk and qgit have had to deal with:\n> > http://kerneltrap.org/mailarchive/git/2007/11/2/379067.\n> \n> I beg to differ. If I skimmed the topic correctly, the problems there\n> were not related to having to parse git's output, but due to the fact\n> that '--topo-order' is a post-processing operation, which takes long.\n> Do read the recent discussion between Linus and Roman about that.\n\nAnd actually if you try to use topo-order internally in C you still\nhave to wait for the post-processing. Which is going to cause your\nUI to lock up because it is single-threaded as both Git and your UI\ntoolkit are probably single threaded. At least by forking out to\ngit-rev-list your UI can respond while the computation is happening\nin a background process.\n \n> Especially since that'd mean that integrating it into other languages\n> (by means of wrappers), such as Python or Ruby, becomes a lot easier.\n\nI'm going to be shot for saying this, but both Python and Ruby\nhave implementations that run on the JVM. So does Git. Want\nto use Git and Python? Use JGit and Jython. :)\n \n> >> There is, use the plumbing, forward compatibility is 95% assured. With\n> >> the exception of major releases, for which any plumbing\n> >> output/behavior changes will be announced in the changelog, usually\n> >> including an explanation on how to change your code to match.\n> >\n> > 95% assured != correct, IMO :)\n> \n> Why not? Junio has a very good reputation of keeping git backwards\n> compatible. The 95% is of course not an actual figure but an\n> expression meant to indicate \"statement is true, minus a few rare case\n> exceptions\".\n\nToo many people have scripts based upon plumbing to make incompatible\nchanges. We'd have all of our users screaming. Remember many Git\nusers are programmers themselves, they will make small home-grown\nscripts based upon Git plumbing to simplify their workflow and\neveryday tasks. They use plumbing precisely because they can trust\nit won't change or break on them.\n\n-- \nShawn.\n"},{"id":"85839","messageId":"bd6139dc0807311510j38d7064dufbf5ded4ad49cddb@mail.gmail.com","threadId":"14773","inReplyTo":"20080731215818.GD24631@spearce.org","subject":"Re: linking libgit.a in C++ projects","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-31T22:10:31Z","receivedAt":"2008-07-31T22:10:31Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 23:58, Shawn O. Pearce wrote:\n> And actually if you try to use topo-order internally in C you still\n> have to wait for the post-processing.....\n\nAye, that's what I was reffering to, thanks for clarifying :).\n\n>> Especially since that'd mean that integrating it into other languages\n>> (by means of wrappers), such as Python or Ruby, becomes a lot easier.\n>\n> I'm going to be shot for saying this, but both Python and Ruby\n> have implementations that run on the JVM. So does Git. Want\n> to use Git and Python? Use JGit and Jython. :)\n\nHeheh, nice plug :P, but thanks but no thanks. I'd rather have\nsomething more native than \"JGit + Jython\", two levels of 'emulation'\ncan't be good!\n\n> Too many people have scripts based upon plumbing to make incompatible\n> changes.....\n\nExactly! :)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85840","messageId":"37fcd2780807311523l2d5a3708xeb09403c0a063898@mail.gmail.com","threadId":"14773","inReplyTo":"ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-31T22:23:20Z","receivedAt":"2008-07-31T22:23:20Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Aug 1, 2008 at 1:44 AM, cte wrote:\n>\n> Using output from the command line utilities as an API has its own set\n> of problems. For instance, check out some of the difficulties that\n> gitk and qgit have had to deal with:\n> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.\n\nThere is no problem with parsing. If you want to receive the output\nin the specific order, Git has to read everything first, and that\nis *slow*. So, --topo-order is convenient but slow, and it is slow\nnot because it is piping data, but because it takes some time to\nread the whole history.\n\n> Digging into\n> the git internals and reusing its core functions will always be more\n> powerful and flexible than parsing command line output.\n\n\"Flexible\" is not a synonym of the word \"useful\". For instance, using\ncore functions will not help you to overcome the aforementioned problem.\nDrawing a graph is NOT what git core functions about. You have to do\nthat in your GUI, and to do that when revisions are given to you in\narbitrary order is not easy. Yet, it is something what good GUI should\nbe capable to handle, because otherwise the response time will be bad.\n\n\nDmitry\n"},{"id":"85849","messageId":"ac9f0f090807311817n551f53a5mb1270e6f4b2a058e@mail.gmail.com","threadId":"14773","inReplyTo":"bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-08-01T01:17:45Z","receivedAt":"2008-08-01T01:17:45Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"> On Thu, Jul 31, 2008 at 23:44, cte wrote:\n>> Using output from the command line utilities as an API has its own set\n>> of problems. For instance, check out some of the difficulties that\n>> gitk and qgit have had to deal with:\n>> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.\n>\n> I beg to differ. If I skimmed the topic correctly, the problems there\n> were not related to having to parse git's output, but due to the fact\n> that '--topo-order' is a post-processing operation, which takes long.\n> Do read the recent discussion between Linus and Roman about that.\n\nDidn't mean to imply that somehow it is no longer a post-processing op if you\naren't using git plumbing. The discussion shows, however, that if gitk\nwas actually\ndoing the revision traversals, then it would be able to trigger events\nthat update the\ngui whenever it wanted, which would have allowed it to implement the\nearly output\nfeature without changing any of the git source. Instead, git-log had\nto be altered to\naddress gitk's needs, and an option was added that users don't\ntypically use. This is\nnot exactly what I would consider spartan programming\n(http://www.codinghorror.com/blog/archives/001148.html),\nplus there are already too many options to remember! Anyways, I\nsuppose it is pointless\nto argue about which approach is better, because both have trade-offs,\nand the correct\npath depends on your use case.\n\n>>> There is, use the plumbing, forward compatibility is 95% assured. With\n>>> the exception of major releases, for which any plumbing\n>>> output/behavior changes will be announced in the changelog, usually\n>>> including an explanation on how to change your code to match.\n>>\n>> 95% assured != correct, IMO :)\n>\n> Why not? Junio has a very good reputation of keeping git backwards\n> compatible. The 95% is of course not an actual figure but an\n> expression meant to indicate \"statement is true, minus a few rare case\n> exceptions\".\n\nDefinitely not questioning his ability to maintain backwards\ncompatibility; it was\nmerely an observation about your strange definition of correct. In school, when\nI completed 95% of a proof, it was never marked as \"correct\", and I\nwas told that I hadn't actually proven anything. Those damn teachers :)\n"},{"id":"85850","messageId":"alpine.LFD.1.10.0807311840240.3277@nehalem.linux-foundation.org","threadId":"14773","inReplyTo":"ac9f0f090807311817n551f53a5mb1270e6f4b2a058e@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-01T01:54:23Z","receivedAt":"2008-08-01T01:54:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 31 Jul 2008, cte wrote:\n>\n> Instead, git-log had to be altered to address gitk's needs, and an \n> option was added that users don't typically use.\n\nActually, no. \n\nI ended up doing a hack to add \"git log --early-output\", and some quick \nhacks to make git use it. But I'm happy to say that gitk doesn't use it \nany more. Gitk just parses the normal git log output, although obviously \nit ends up needing enough data to be able to fill in the gaps (ie it uses \nthe \"--parents\" flag to get the rewritten parenthood info and the merges \nto keep it together).\n\nSo yeah, we have some options that enable output that simply doesn't make \n_sense_ to humans, but does when you are post-processing it (git has \nalways had those, since it very much was about scripting from day one), \nbut no, at least gitk doesn't use any really odd ones.\n\nIt literally does\n\n\tgit log --no-color -z --pretty=raw --parents --boundary\n\n(plus the args the user gave it). The --no-color turns off color if it's \nenabled by default.\n\nThe -z makes it the git log output a bit easier to parse by using a NUL \ncharacter between commits.\n\nThe --pretty=raw is just to give the full/raw commit info - like giving \nthe timestamps in the native raw format that is much easier to parse than \nany human-readable format.\n\nThe --parents I already mentioned - it is what makes you able to stitch \nthe commits together (and it's useful for other things too: any scripts \nthat look for merges will tend to use it, for example)\n\nAnd the --boundary is to show the commits that aren't part of the actual \nselected set in gray.\n\nIt's all pretty generic, in other words. The -z option is purely for \nmachine parsing, the others _can_ actually be useful even for humans (eg, \n--boundary together with --left-right and --pretty=oneline actually is \nvery readable if you are used to that format).\n\nSo it's very true that git in general is geared towards scripting (and \nwe've often added things to make it even more so), but no, your particular \ncomplaint isn't true. gitk doesn't do anything really strange.\n\n\t\tLinus\n"},{"id":"85852","messageId":"ac9f0f090807311912h31c47f8ey43e0109c38f5a91d@mail.gmail.com","threadId":"14773","inReplyTo":"alpine.LFD.1.10.0807311840240.3277@nehalem.linux-foundation.org","subject":"Re: linking libgit.a in C++ projects","fromName":"cte","fromEmail":"cestreich@gmail.com","sentAt":"2008-08-01T02:12:37Z","receivedAt":"2008-08-01T02:12:37Z","isPatch":false,"sender":{"key":"cestreich@gmail.com","avatar":"https://gravatar.com/avatar/2234cd64cd37028bde432c275668da967f5303327e0fb5159ebf76db81a7fd43?d=mp&s=160"},"body":"> So it's very true that git in general is geared towards scripting (and\n> we've often added things to make it even more so), but no, your particular\n> complaint isn't true. gitk doesn't do anything really strange.\n\nYeah, I guess that's why I like using git so much; a few piped\ncommands and a script or two, and you can do some pretty rad stuff.\n"},{"id":"86096","messageId":"20080803201211.GA11121@steel.home","threadId":"14773","inReplyTo":"32541b130807311155v50ee6ddaha1bba2f56e9bd61d@mail.gmail.com","subject":"Re: linking libgit.a in C++ projects","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-03T20:12:11Z","receivedAt":"2008-08-03T20:12:11Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Avery Pennarun, Thu, Jul 31, 2008 20:55:26 +0200:\n> On 7/31/08, Alex Riesen wrote:\n> > Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:\n> > > Produce a C file and header that defines some stable API to your\n> > > GUI application, that does not expose any git internal headers.\n> > > Then compile that, say git_api.c, with C compiler in Makefile\n> > > and extern \"C\" link that file to your C++ application. This will\n> > > completely insulate you from any git code.\n> >\n> > no, it wont. He still have to resolve name conflicts at the link time.\n> \n> Language keywords (as opposed to function names) like 'new' and\n> 'typename' are definitely not exported to the object files. Moreover,\n> function parameter names aren't either.\n> \n\nDidn't mean them. Meant the globally visible names. libgit does not\nuse a prefix for its exported symbols. They will clash with the\nsymbols of the programs it is linked to.\n"},{"id":"86164","messageId":"4896C472.9070002@panasas.com","threadId":"14773","inReplyTo":"20080803201211.GA11121@steel.home","subject":"Re: linking libgit.a in C++ projects","fromName":"Boaz Harrosh","fromEmail":"bharrosh@panasas.com","sentAt":"2008-08-04T08:57:22Z","receivedAt":"2008-08-04T08:57:22Z","isPatch":false,"sender":{"key":"bharrosh@panasas.com","avatar":"https://gravatar.com/avatar/347e426f8ca0409f6891ceeefd4c3c2d8769608382323057efeaa362b4c3dbf3?d=mp&s=160"},"body":"Alex Riesen wrote:\n> Avery Pennarun, Thu, Jul 31, 2008 20:55:26 +0200:\n>> On 7/31/08, Alex Riesen wrote:\n>>> Boaz Harrosh, Thu, Jul 31, 2008 15:04:50 +0200:\n>>>> Produce a C file and header that defines some stable API to your\n>>> > GUI application, that does not expose any git internal headers.\n>>> > Then compile that, say git_api.c, with C compiler in Makefile\n>>> > and extern \"C\" link that file to your C++ application. This will\n>>> > completely insulate you from any git code.\n>>>\n>>> no, it wont. He still have to resolve name conflicts at the link time.\n>> Language keywords (as opposed to function names) like 'new' and\n>> 'typename' are definitely not exported to the object files. Moreover,\n>> function parameter names aren't either.\n>>\n> \n> Didn't mean them. Meant the globally visible names. libgit does not\n> use a prefix for its exported symbols. They will clash with the\n> symbols of the programs it is linked to.\n> \n\nBut that's a problem for C programs, C++ programs will not have that \nproblem, right? ;-)\n\nWith C programs these git symbols can be avoided.\n\nBoaz\n"},{"id":"86198","messageId":"f35478f50808040752j52a8ac0dn56d15d2151dc5308@mail.gmail.com","threadId":"14773","inReplyTo":"20080731215818.GD24631@spearce.org","subject":"Re: linking libgit.a in C++ projects","fromName":"Steve Frécinaux","fromEmail":"nudrema@gmail.com","sentAt":"2008-08-04T14:52:07Z","receivedAt":"2008-08-04T14:52:07Z","isPatch":false,"sender":{"key":"nudrema@gmail.com","avatar":null},"body":"On Thu, Jul 31, 2008 at 11:58 PM, Shawn O. Pearce wrote:\n>> Especially since that'd mean that integrating it into other languages\n>> (by means of wrappers), such as Python or Ruby, becomes a lot easier.\n>\n> I'm going to be shot for saying this, but both Python and Ruby\n> have implementations that run on the JVM. So does Git. Want\n> to use Git and Python? Use JGit and Jython. :)\n\nThere is also the \"stores\" branch from pygit [1] that implements pack\nand object reading natively in python. Anyway implementing more than\nthat (ie, packing and such things) natively is clearly harder and\ntakes more work for less efficiency than making bindings around a\nlibified git...\n\n[1] http://code.istique.net/?p=pygit.git;a=shortlog;h=refs/heads/stores\nDon't mind the 50X error, just refresh... broken server.\n"}]}