{"thread":{"id":"9172","subject":"[ANNOUNCE]: PyGit and libgit-thin","startedAt":"2007-07-23T12:35:47Z","lastAt":"2007-07-25T21:21:43Z","messageCount":5,"participants":["Luiz Fernando N. Capitulino","Yann Dirson","David Kastrup","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48305","messageId":"e28f90730707230535q33658efevf665d795cf1df87c@mail.gmail.com","threadId":"9172","inReplyTo":null,"subject":"[ANNOUNCE]: PyGit and libgit-thin","fromName":"Luiz Fernando N. Capitulino","fromEmail":"lcapitulino@gmail.com","sentAt":"2007-07-23T12:35:47Z","receivedAt":"2007-07-23T12:35:47Z","isPatch":false,"sender":{"key":"lcapitulino@gmail.com","avatar":null},"body":"Hi there,\n\nI'm the student working on the gsoc libfication project with Shawn and it\nhas reached the point where I need some feedback in order to decide\nwhat to do next.\n\nThe project's goal was/is to change what is needed in GIT in order to make\nit easier to use as library. This is useful for 'external'\napplications which wants\nto be able to perform GIT operations w/o having to fork-exec GIT process (and\nalso w/o having to parse git's programs output). Example of such applications\nare language bindings and IDEs' plugins.\n\nHowever, the need for this is not a consensus. Some disagree (Linus included\nI think) and IIRC Junio has stated that he'd probably be against a stable API.\n\nSo, in order to make things simple and have a clear separation of what is\nadditional interface not needed by GIT we (Shawn and I) have decided to work\non a new library which uses git's low-level interface.\n\nThat library is called libgit-thin and currently it's capable of\nrevision listing,\ncommit parsing and some other things.\n\nTo demonstrate how to use the library, I've also written a python module which\nexports to python all the library's functionality.\n\nNow I need to know whether this' really useful to other people and if so, what\nwould be missing for you to start using it.\n\nThe project can be found at:\n\nhttp://repo.or.cz/w/git/libgit-gsoc.git\n\nLook into the 'libgit-thin' directory. Note that it's a fork of\nJunio's tree, so if you have\nhis repository around do:\n\n$ git clone --reference /path/to/junio/repo git://repo.or.cz/git/libgit-gsoc.git\n\nA demo of the python's module is available here:\n\nhttp://repo.or.cz/w/git/libgit-gsoc.git?a=blob;f=libgit-thin/pygit/demo.txt;h=f4f9cb726e06ac18a3bf125f3caa7c50dd095361;hb=HEAD\n\nPlease, keep in mind that the library's code is still experimental and most of\nthe python module's code is untested.\n\nIt's also important to say that there's no much documentation\navailable, you'll have\nto know a bit about git's implementation for this stuff to be useful for you.\n\n Thanks a lot for reading this and any kind of feedback is welcome.\n\n-- \nLuiz Fernando N. Capitulino\n"},{"id":"48580","messageId":"20070725195010.GA30277@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"9172","inReplyTo":"e28f90730707230535q33658efevf665d795cf1df87c@mail.gmail.com","subject":"Re: [ANNOUNCE]: PyGit and libgit-thin","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-07-25T19:50:10Z","receivedAt":"2007-07-25T19:50:10Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Jul 23, 2007 at 09:35:47AM -0300, Luiz Fernando N. Capitulino wrote:\n> Now I need to know whether this' really useful to other people and\n> if so, what would be missing for you to start using it.\n\nThe python module would really be useful to StGIT.  Currently, an\nstgit commands typically has to fork several git commands at least,\nand using library calls instead would surely help with the\nperformance.\n\nI had a quick look at the current pygit API (as described in the\nREADME), and I find the current revlist one somewhat confusing.  Why\nusing post-contructor methods, and not using named args in the\nconstructor itself ?\n\nThat is, the example reading:\n\n>>> rv = repo.revlist()\n>>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')\n>>> rv.count = 10\n>>> rv.show_merges()\n>>> for commit in rv:\n...  print commit.id()\n... \n\n\nwould be IMHO much nicer to use as:\n\n>>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),\n...                   count = 10,\n...                   show_merges = true)\n...\n>>> for commit in rv:\n...  print commit.id()\n... \n\n\nWhat do you think ?\n\nBest regards,\n-- \nYann\n"},{"id":"48581","messageId":"85odi08ddk.fsf@lola.goethe.zz","threadId":"9172","inReplyTo":"20070725195010.GA30277@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [ANNOUNCE]: PyGit and libgit-thin","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-25T19:57:59Z","receivedAt":"2007-07-25T19:57:59Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Yann Dirson <ydirson@altern.org> writes:\n\n> I had a quick look at the current pygit API (as described in the\n> README), and I find the current revlist one somewhat confusing.  Why\n> using post-contructor methods, and not using named args in the\n> constructor itself ?\n>\n> That is, the example reading:\n>\n>>>> rv = repo.revlist()\n>>>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')\n>>>> rv.count = 10\n>>>> rv.show_merges()\n>>>> for commit in rv:\n> ...  print commit.id()\n> ... \n>\n>\n> would be IMHO much nicer to use as:\n>\n>>>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),\n> ...                   count = 10,\n> ...                   show_merges = true)\n> ...\n>>>> for commit in rv:\n> ...  print commit.id()\n> ... \n>\n>\n> What do you think ?\n\nNicer to use if the commands and their options originate from withing\nPython.  But if Python parses arguments from somewhere else and passes\nthem on, the former interface leads to much cleaner code AFAICS.\nPasting together a named argument call piecemeal is not going to be\npretty, I should think.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48592","messageId":"e28f90730707251355vc1fc47ftc7851324ddfad771@mail.gmail.com","threadId":"9172","inReplyTo":"20070725195010.GA30277@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: [ANNOUNCE]: PyGit and libgit-thin","fromName":"Luiz Fernando N. Capitulino","fromEmail":"lcapitulino@gmail.com","sentAt":"2007-07-25T20:55:51Z","receivedAt":"2007-07-25T20:55:51Z","isPatch":false,"sender":{"key":"lcapitulino@gmail.com","avatar":null},"body":"Hi Yann,\n\nOn 7/25/07, Yann Dirson <ydirson@altern.org> wrote:\n> On Mon, Jul 23, 2007 at 09:35:47AM -0300, Luiz Fernando N. Capitulino wrote:\n> > Now I need to know whether this' really useful to other people and\n> > if so, what would be missing for you to start using it.\n>\n> The python module would really be useful to StGIT.  Currently, an\n> stgit commands typically has to fork several git commands at least,\n> and using library calls instead would surely help with the\n> performance.\n\n Cool.\n\n> I had a quick look at the current pygit API (as described in the\n> README), and I find the current revlist one somewhat confusing.  Why\n> using post-contructor methods, and not using named args in the\n> constructor itself ?\n>\n> That is, the example reading:\n>\n> >>> rv = repo.revlist()\n> >>> rv.include('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9')\n> >>> rv.count = 10\n> >>> rv.show_merges()\n> >>> for commit in rv:\n> ...  print commit.id()\n> ...\n>\n>\n> would be IMHO much nicer to use as:\n>\n> >>> rv = repo.revlist(include=('8d9107e8c50e1c4ff43c91c8841805833f3ecfb9'),\n> ...                   count = 10,\n> ...                   show_merges = true)\n> ...\n> >>> for commit in rv:\n> ...  print commit.id()\n> ...\n>\n>\n> What do you think ?\n\n I think you're right, that'd be nicer.\n\n The problem is that the revlist operation accepts a lot of options,\nand to change\nall (or a big amount of them) would force one to build a very length list of\narguments.\n\n Currently we have just a few, but we'll add more in the future.\n\n Also, I think that it won't be that nice to play with include() and exclude(),\nsince you can call them more than once.\n\n I'm not sure whether in its current state the module (plus the library) is\nuseful for stgit.\n\n Please, feel to make questions and to ask for what'd be missing for you\nto adopt it.\n\n I'm a quilt user and completely forgot that stgit is written in python. I'll\ntake a look.\n\n Thanks for your comments,\n\n-- \nLuiz Fernando N. Capitulino\n"},{"id":"48593","messageId":"20070725212143.GB3808@efreet.light.src","threadId":"9172","inReplyTo":"85odi08ddk.fsf@lola.goethe.zz","subject":"Re: [ANNOUNCE]: PyGit and libgit-thin","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-07-25T21:21:43Z","receivedAt":"2007-07-25T21:21:43Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Jul 25, 2007 at 21:57:59 +0200, David Kastrup wrote:\n> Nicer to use if the commands and their options originate from withing\n> Python.  But if Python parses arguments from somewhere else and passes\n> them on, the former interface leads to much cleaner code AFAICS.\n> Pasting together a named argument call piecemeal is not going to be\n> pretty, I should think.\n\nYou just put all the arguments in a dict and use the ** syntax. And if you\nalready get the arguments in a dict from the parser, it's even nicer.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"}]}