{"thread":{"id":"26879","subject":"GSoC questions","startedAt":"2011-03-27T09:20:58Z","lastAt":"2011-04-01T21:05:13Z","messageCount":12,"participants":["Alexandru Sutii","Jonathan Nieder","Jeff King","Vicent Marti","Motiejus Jakštys","Vincent van Ravesteijn"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164387","messageId":"AANLkTinTM8hQpcahGgDyB4UJvGbdN0xyp65wL5PDQGKa@mail.gmail.com","threadId":"26879","inReplyTo":null,"subject":"GSoC questions","fromName":"Alexandru Sutii","fromEmail":"sutii.alex@gmail.com","sentAt":"2011-03-27T09:20:58Z","receivedAt":"2011-03-27T09:20:58Z","isPatch":false,"sender":{"key":"sutii.alex@gmail.com","avatar":"https://gravatar.com/avatar/e4b21b19490f2fbb54e34227dc66f1a6eec34c257a0c1c8d4dbcb67f644eb447?d=mp&s=160"},"body":"Hello!\n\nMy name is Alexandru Sutii and I would like to participate as a student at GSoc.\nI am interested in two projects from your list:\n- Build a minimal Git client based on libgit2\n- Port Git to Android\nMy questions are:\n- How important are these projects for the community?\n- Should I provide a patch in order to prove that I am suited for one of these\nprojects?\n  If so, what specifically should I implement?\n\nThank you,\nAlexandru.\n"},{"id":"164400","messageId":"20110328001152.GA11294@elie","threadId":"26879","inReplyTo":"AANLkTinTM8hQpcahGgDyB4UJvGbdN0xyp65wL5PDQGKa@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-28T00:11:53Z","receivedAt":"2011-03-28T00:11:53Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nAlexandru Sutii wrote:\n\n> I am interested in two projects from your list:\n> - Build a minimal Git client based on libgit2\n> - Port Git to Android\n> My questions are:\n> - How important are these projects for the community?\n> - Should I provide a patch in order to prove that I am suited for one of these\n> projects?\n>   If so, what specifically should I implement?\n\nThanks for writing.  The \"minimal Git client\" task seems like a\npopular one.  Luckily that is not a fatal problem --- git has many\nsubcommands, so even if every proposal is about that, it could be\npossible to subdivide the work and produce something interesting.\n\nSome reading matter:\n\n http://thread.gmane.org/gmane.comp.version-control.git/99608/focus=99682\n http://thread.gmane.org/gmane.comp.version-control.git/169498/focus=169517\n http://thread.gmane.org/gmane.comp.version-control.git/169498/focus=169762\n http://thread.gmane.org/gmane.comp.version-control.git/170032/focus=170076\n\nIs there some particular part of git functionality you would like to\nfocus on (history creation, history mining, object store maintenance,\nconfiguration, transport)?  The list of low-level commands (plumbing)\nin the git manual might be a good place to get an idea of the scope.\n\nThe ideas page mentions areas in which libgit2 functionality is\nincomplete --- depending on your interest, you might want to focus on\none of these (so the project would be to add functionality to libgit2\nas well as using it) or to steer clear of them (to focus on\nfunctionality libgit2 already has).\n\nSo, to make a long story short: there is something sneaky about us\npresenting this idea, since there is so much room for choice.  As your\nproject becomes more precise it should be possible for people on the\nlist to give more detailed advice.\n\nCc-ing the libgit2 list and Jeff King for more hints.\n\nAs for porting git to Android: that idea is less concrete to me.  A\nnative Android app would presumably be in Java, so most likely your\nbest bet is to talk to someone involved in the JGit project[1].\n\nAnother note.  Please feel free to venture beyond projects listed on\nthe ideas page.  For example the 2010 ideas page contains some gems:\n\n https://git.wiki.kernel.org/index.php/SoC2010Ideas#Several_small_projects_improving_msysGit\n\nas does the 2008 page if you can get Nicolas Pitre on board :)\n\n https://git.wiki.kernel.org/index.php/SoC2008Ideas#Implement_pack_v4.2Fv5_for_higher_compression\n\nReally, if you name any git-related topic you're interested in,\nchances are we can come up together with something valuable and\ninteresting to work on in that area.\n\nLastly, as far as patches go: yes, it would be excellent (and it would\nshow initiative) to offer an experience of what it is like to work\nwith you (if you end up finding time for this).\n\nGit may misbehave; or while getting up to speed on some aspect of its\nbehavior you may find some documentation confusing; or you may wonder,\n\"why is this code doing such a slow/unreliable/otherwise insane\nthing?\"  When the moment comes, look straight to\nDocumentation/SubmittingPatches and it will tell what to do. :)\n\nGood luck with whatever project you decide,\nJonathan\n\n[1] http://wiki.eclipse.org/Google_Summer_of_Code_2011_Ideas#Ideas_submission\nhttp://eclipse.org/jgit/developers/\n"},{"id":"164437","messageId":"20110328143506.GC14763@sigill.intra.peff.net","threadId":"26879","inReplyTo":"20110328001152.GA11294@elie","subject":"Re: GSoC questions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-28T14:35:06Z","receivedAt":"2011-03-28T14:35:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 27, 2011 at 07:11:53PM -0500, Jonathan Nieder wrote:\n\n> The ideas page mentions areas in which libgit2 functionality is\n> incomplete --- depending on your interest, you might want to focus on\n> one of these (so the project would be to add functionality to libgit2\n> as well as using it) or to steer clear of them (to focus on\n> functionality libgit2 already has).\n> \n> So, to make a long story short: there is something sneaky about us\n> presenting this idea, since there is so much room for choice.  As your\n> project becomes more precise it should be possible for people on the\n> list to give more detailed advice.\n\nYes. I didn't write those ideas on the idea page, but I do like their\nsneakiness. On the ideas I put up, I also tried to be a little bit\nvague.\n\nBecause I'd really rather see a student not do a proposal based on one\nof our ideas as a checklist of things to code. I'd much rather give them\na _problem_, then come up with and implement their own solution,\nfiguring out the requirements and the best way to go about it\nthemselves (with hints from the community, of course; none of us works\nin a vacuum, and certainly somebody new to the project isn't going to\nalways know the best way to go about things).\n\nBut GSoC (IMHO) is not just about getting code written. It's also about\nshowing students what it's like to take part in open source projects,\nand to see a problem in need of solving and scratch that itch. And from\nthe project's perspective, hopefully that gets the student addicted to\nscratching itches and they keep doing it.\n\n> Another note.  Please feel free to venture beyond projects listed on\n> the ideas page.  For example the 2010 ideas page contains some gems:\n\nI very much agree with this. Though I would caution students to talk to\nthe community a bit before doing a proposal for something out of the\nblue. Because often people have tried and failed at something similar\nbefore, and knowing the context helps. So post to the list and say \"I am\nthinking of doing X. Has anybody done something like it before? What\nwould be the best way to go about?\"\n\n-Peff\n"},{"id":"164490","messageId":"AANLkTikGb1=Rtz-T9p=u+X32KpL2AXq0AELdSJ2NMHrW@mail.gmail.com","threadId":"26879","inReplyTo":"20110328001152.GA11294@elie","subject":"Re: GSoC questions","fromName":"Alexandru Sutii","fromEmail":"sutii.alex@gmail.com","sentAt":"2011-03-28T20:26:47Z","receivedAt":"2011-03-28T20:26:47Z","isPatch":false,"sender":{"key":"sutii.alex@gmail.com","avatar":"https://gravatar.com/avatar/e4b21b19490f2fbb54e34227dc66f1a6eec34c257a0c1c8d4dbcb67f644eb447?d=mp&s=160"},"body":"> Is there some particular part of git functionality you would like to\n> focus on (history creation, history mining, object store maintenance,\n> configuration, transport)?  The list of low-level commands (plumbing)\n> in the git manual might be a good place to get an idea of the scope.\n>\n> The ideas page mentions areas in which libgit2 functionality is\n> incomplete --- depending on your interest, you might want to focus on\n> one of these (so the project would be to add functionality to libgit2\n> as well as using it) or to steer clear of them (to focus on\n> functionality libgit2 already has).\n\nHello again! Thanks for your and Jeff's reply.\n\nI have decided on \"minimal Git client based on libgit2\" project. I have looked\nover the git manual page and I would like to work on manipulation commands\nfunctionality. I am also open for adding functionality to libgit2 as\nwell as using it.\n\nI have read the references from your mail and I am currently trying to\nunderstand project's architecture, as I am totally new to git's source code.\nHope I will manage to identify the source code parts that interest me in\na short time and maybe realize to implement something.\n\nIn the meantime I would greatly appreciate some guidelines where to look.\n\n--Alex.\n"},{"id":"164495","messageId":"AANLkTink4wVb6O+yVm=HUh_s1GhKhyL4baqYGe=XFu04@mail.gmail.com","threadId":"26879","inReplyTo":"AANLkTikGb1=Rtz-T9p=u+X32KpL2AXq0AELdSJ2NMHrW@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Vicent Marti","fromEmail":"vicent@github.com","sentAt":"2011-03-28T20:52:13Z","receivedAt":"2011-03-28T20:52:13Z","isPatch":false,"sender":{"key":"vicent@github.com","avatar":"https://gravatar.com/avatar/9d57a2b1e3137bf84342ac1dfdf1cde409b86e8fda5397d05f40f17fa5b84a63?d=mp&s=160"},"body":"Hey Alex,\n\nI'm glad to see you're interested on the minimal git client task.\n\nHere are some places to get you started on writing your proposal:\n\nhttp://libgit2.github.com/libgit2/index.html (the full API\ndocumentation -- priceless)\nhttp://libgit2.github.com/api.html (the usage guide, with examples)\nhttps://github.com/libgit2 (the list of language bindings, so you can\nsee real-life usage samples)\n\nAlso, I have to agree with Jeff once again: Start researching and\nimpress us with an awesome application that shows how are you planning\nto solve the problem you are facing -- in this case writing a minimal\ngit client.\n\nRemember that the sooner your application gets on Melange, the more\nfeedback it will receive!\n\nCheers,\nVicent\n\n\nOn Mon, Mar 28, 2011 at 11:26 PM, Alexandru Sutii <sutii.alex@gmail.com> wrote:\n>> Is there some particular part of git functionality you would like to\n>> focus on (history creation, history mining, object store maintenance,\n>> configuration, transport)?  The list of low-level commands (plumbing)\n>> in the git manual might be a good place to get an idea of the scope.\n>>\n>> The ideas page mentions areas in which libgit2 functionality is\n>> incomplete --- depending on your interest, you might want to focus on\n>> one of these (so the project would be to add functionality to libgit2\n>> as well as using it) or to steer clear of them (to focus on\n>> functionality libgit2 already has).\n>\n> Hello again! Thanks for your and Jeff's reply.\n>\n> I have decided on \"minimal Git client based on libgit2\" project. I have looked\n> over the git manual page and I would like to work on manipulation commands\n> functionality. I am also open for adding functionality to libgit2 as\n> well as using it.\n>\n> I have read the references from your mail and I am currently trying to\n> understand project's architecture, as I am totally new to git's source code.\n> Hope I will manage to identify the source code parts that interest me in\n> a short time and maybe realize to implement something.\n>\n> In the meantime I would greatly appreciate some guidelines where to look.\n>\n> --Alex.\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"},{"id":"164766","messageId":"AANLkTinZ2zbhCRAqAYkiAa1=K8aUhcAuEe6Q_gO-v2h_@mail.gmail.com","threadId":"26879","inReplyTo":"AANLkTink4wVb6O+yVm=HUh_s1GhKhyL4baqYGe=XFu04@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Alexandru Sutii","fromEmail":"sutii.alex@gmail.com","sentAt":"2011-03-31T09:36:15Z","receivedAt":"2011-03-31T09:36:15Z","isPatch":false,"sender":{"key":"sutii.alex@gmail.com","avatar":"https://gravatar.com/avatar/e4b21b19490f2fbb54e34227dc66f1a6eec34c257a0c1c8d4dbcb67f644eb447?d=mp&s=160"},"body":"> Here are some places to get you started on writing your proposal:\n>\n> http://libgit2.github.com/libgit2/index.html (the full API\n> documentation -- priceless)\n> http://libgit2.github.com/api.html (the usage guide, with examples)\n> https://github.com/libgit2 (the list of language bindings, so you can\n> see real-life usage samples)\n\nHello again!\n\nFirst of all thanks a lot for the references. You have helped me a lot.\n\n> Also, I have to agree with Jeff once again: Start researching and\n> impress us with an awesome application that shows how are you planning\n> to solve the problem you are facing -- in this case writing a minimal\n> git client.\n>\n> Remember that the sooner your application gets on Melange, the more\n> feedback it will receive!\n\nI began implementing the minimal git client[1]. I have implemented the\n\"git-mktag\" command. For this I have modified the \"mktag.c\" file from\nthe \"builtin\" directory in order to make it run with libgit2. Basically the\ninput file verification code is the same with the original one. I have just\nextracted the sha1, the object type, the tag name, the tagger, the\ncomment and created a tag with git_tag_create.\n\nI have also used the original \"usage.c\" and \"git-compat-util.h\" for\nerror handling.\nIs there a problem if the git2 client will reuse non-gitcore code, such\nas string parsing code, parameter parsing code, etc?\n\nCan someone look on my code and give me some feedback?\n\nJust before ending the implementation of the mktag command I have\nstarted thinking that maybe there was no need to reimplement this\ncommand, as it can be considered that libgit2 already has this feature.\nEven if it is so I am not sorry I did this, because by reimplementig it I\nhad the chance to get used with git code and with libgit2 API.\n\n--Alex\n\n[1] https://github.com/sutiialex/Git2\n"},{"id":"164771","messageId":"20110331110605.GA14892@jakstys.lt","threadId":"26879","inReplyTo":"AANLkTinZ2zbhCRAqAYkiAa1=K8aUhcAuEe6Q_gO-v2h_@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-03-31T11:06:05Z","receivedAt":"2011-03-31T11:06:05Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Thu, Mar 31, 2011 at 12:36:15PM +0300, Alexandru Sutii wrote:\n> I began implementing the minimal git client[1]. I have implemented the\n> \"git-mktag\" command. For this I have modified the \"mktag.c\" file from\n> the \"builtin\" directory in order to make it run with libgit2. Basically the\n> input file verification code is the same with the original one. I have just\n> extracted the sha1, the object type, the tag name, the tagger, the\n> comment and created a tag with git_tag_create.\n\nHi there,\n\nI started git2 client a couple of days ago and implemented a rough\nversion of rev-list.c (which shows rev-list of HEAD. It is here:\nhttps://github.com/Motiejus/git2/\n\nVincent van Ravesteijn forked and made some modifications:\nhttps://github.com/vfr-nl/git2/\nThanks to him for CMakeLists.txt.\n\n> \n> I have also used the original \"usage.c\" and \"git-compat-util.h\" for\n> error handling.  Is there a problem if the git2 client will reuse\n> non-gitcore code, such as string parsing code, parameter parsing code,\n> etc?\n\nI think this is what it has to be like. Provided it adds no\nrequirements and license issues.\n\n> \n> Can someone look on my code and give me some feedback?\n\nYou have done a good job in creating handlers and hooking up the\nrepository. Thank you.\n\n> \n> Just before ending the implementation of the mktag command I have\n> started thinking that maybe there was no need to reimplement this\n> command, as it can be considered that libgit2 already has this\n> feature.  Even if it is so I am not sorry I did this, because by\n> reimplementig it I had the chance to get used with git code and with\n> libgit2 API.\n\nDon't know about the actual tag implementation, but in any case, the\nwrapper (glue) code around the tag very helpful.\n\nBest,\nMotiejus\n"},{"id":"164777","messageId":"AANLkTi=TOYOj2HWzy62G24Kg=NZC5X1=psA3GDhaH3Hc@mail.gmail.com","threadId":"26879","inReplyTo":"AANLkTinZ2zbhCRAqAYkiAa1=K8aUhcAuEe6Q_gO-v2h_@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-03-31T11:58:23Z","receivedAt":"2011-03-31T11:58:23Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"On Thu, Mar 31, 2011 at 11:36 AM, Alexandru Sutii <sutii.alex@gmail.com> wrote:\n> I have also used the original \"usage.c\" and \"git-compat-util.h\" for\n> error handling.\n> Is there a problem if the git2 client will reuse non-gitcore code, such\n> as string parsing code, parameter parsing code, etc?\n\nI guess the git2 client will consist solely of non-gitcore code, as\nall the gitcore code will be part of libgit2 eventually.\n\nI expect the transition to be not so difficult for many commands, but\nthe challenge I see is to do it not by 'reusing' git code, but by\n'sharing' the code. Otherwise we end up with a second Git and someone\nshould spend a lifetime to keep the reused code in synchronisation\nwith the git repo.\n\nThis might, however, require some (major) refactorization to the Git\ncode. I don't know whether that will be supported by everyone.\n\nOn the other hand, we will get the bonus that using libgit2 in the\nupstream git code is then becoming more trivial.\n\nMaybe I'm aiming at too much here. It could well be that it is worth\nwriting the minimal git client to just be able to test libgit2 using\nthe git tests. Does anyone want to comment ?\n\nVincent\n"},{"id":"164811","messageId":"AANLkTikMsQHL9RMm=uOse+OObavMNc=PJE7aOqA-WMkY@mail.gmail.com","threadId":"26879","inReplyTo":"AANLkTi=TOYOj2HWzy62G24Kg=NZC5X1=psA3GDhaH3Hc@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Alexandru Sutii","fromEmail":"sutii.alex@gmail.com","sentAt":"2011-03-31T18:34:15Z","receivedAt":"2011-03-31T18:34:15Z","isPatch":false,"sender":{"key":"sutii.alex@gmail.com","avatar":"https://gravatar.com/avatar/e4b21b19490f2fbb54e34227dc66f1a6eec34c257a0c1c8d4dbcb67f644eb447?d=mp&s=160"},"body":"> I guess the git2 client will consist solely of non-gitcore code, as\n> all the gitcore code will be part of libgit2 eventually.\n>\n> I expect the transition to be not so difficult for many commands, but\n> the challenge I see is to do it not by 'reusing' git code, but by\n> 'sharing' the code. Otherwise we end up with a second Git and someone\n> should spend a lifetime to keep the reused code in synchronisation\n> with the git repo.\n>\n> This might, however, require some (major) refactorization to the Git\n> code. I don't know whether that will be supported by everyone.\n>\n> On the other hand, we will get the bonus that using libgit2 in the\n> upstream git code is then becoming more trivial.\n>\n> Maybe I'm aiming at too much here. It could well be that it is worth\n> writing the minimal git client to just be able to test libgit2 using\n> the git tests. Does anyone want to comment ?\n\nHello!\n\nThere have been a lot on discussions on the mailing list regarding\non what this client should look like and I understand that we are\nexpected to come with a specific approach. Also I understand there is\nno interest for this project to become large.\n\nConsidering this circumstances I think we should implement the client\nwith the basic commands by reusing git's high level code. I am for building\nit independently of the git's mainstream.\n\nAnyway I am open to any proposals. Comments are still welcome.\n\n--Alex\n"},{"id":"164826","messageId":"20110331192758.GD16981@sigill.intra.peff.net","threadId":"26879","inReplyTo":"AANLkTi=TOYOj2HWzy62G24Kg=NZC5X1=psA3GDhaH3Hc@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Jeff King","fromEmail":"peff@github.com","sentAt":"2011-03-31T19:27:58Z","receivedAt":"2011-03-31T19:27:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 31, 2011 at 01:58:23PM +0200, Vincent van Ravesteijn wrote:\n\n> On Thu, Mar 31, 2011 at 11:36 AM, Alexandru Sutii <sutii.alex@gmail.com> wrote:\n> > I have also used the original \"usage.c\" and \"git-compat-util.h\" for\n> > error handling.\n> > Is there a problem if the git2 client will reuse non-gitcore code, such\n> > as string parsing code, parameter parsing code, etc?\n> \n> I guess the git2 client will consist solely of non-gitcore code, as\n> all the gitcore code will be part of libgit2 eventually.\n> \n> I expect the transition to be not so difficult for many commands, but\n> the challenge I see is to do it not by 'reusing' git code, but by\n> 'sharing' the code. Otherwise we end up with a second Git and someone\n> should spend a lifetime to keep the reused code in synchronisation\n> with the git repo.\n> \n> This might, however, require some (major) refactorization to the Git\n> code. I don't know whether that will be supported by everyone.\n\nI had sort of assumed that git-core code would be taken as inspiration,\nbut that it would be an entirely new implementation, based around the\nerror handling and build infrastructure provided by libgit2.\n\nAnd obviously libgit2 isn't going to provide everything you need. For\nexample, in the mktag implementation that Alex posted, there's still a\nbig verify_and_create_tag() function. I would prefer to see that code\nbroken into library-sized chunks and added to libgit2 itself, with the\neventual goal that mktag.c could consist of a very short main() function\nthat just parses options calls into the library (and yeah, I realize\nthat things are not always so simple, but it is a goal to work towards).\n\nSo when starting with a command, rather than trying to port code from\ngit.git, look at what it does and say \"how would I do this in libgit2?\nWhat else needs to be implemented in the library before I can do it?\".\nAnd then write the bulk of your code for libgit2, filling in those gaps\nin functionality, and as a final step make the actual executable\ncommand.\n\nIn this case, one of the things that is lacking is the die() error\nhandling. In general, that is not something libgit2 wants, because its\ngoal is to pass errors back up the call chain. Another thing that is\nmissing is option-parsing (though mktag doesn't need it). Again, not\nsomething that libgit2 wants to use.\n\nBut maybe those are things that libgit2 should be providing to callers.\nOr maybe they should be spun off into their own separate utility\nlibrary. But in either case, they should probably be pulled out of core\ngit, cleaned up to make them fit for library use, and then made part of\nlibgit2.\n\n-Peff\n"},{"id":"164827","messageId":"20110331193128.GE16981@sigill.intra.peff.net","threadId":"26879","inReplyTo":"AANLkTikMsQHL9RMm=uOse+OObavMNc=PJE7aOqA-WMkY@mail.gmail.com","subject":"Re: GSoC questions","fromName":"Jeff King","fromEmail":"peff@github.com","sentAt":"2011-03-31T19:31:28Z","receivedAt":"2011-03-31T19:31:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 31, 2011 at 09:34:15PM +0300, Alexandru Sutii wrote:\n\n> > Maybe I'm aiming at too much here. It could well be that it is worth\n> > writing the minimal git client to just be able to test libgit2 using\n> > the git tests. Does anyone want to comment ?\n> \n> Hello!\n> \n> There have been a lot on discussions on the mailing list regarding\n> on what this client should look like and I understand that we are\n> expected to come with a specific approach. Also I understand there is\n> no interest for this project to become large.\n\nIt's OK if the project is large; it's inherently a big thing. But it's\nimportant to bite off a small enough, useful chunk of it and work on\nthat. One, because you want something small enough to finish in the GSoC\ntime-frame. But two, because a small, solid start on a larger project is\nmuch more useful to the community as a whole than a larger chunk that is\nnot-so-solid. Because people in the community (and you, if you want to\nkeep working on it!) may pick up the project from its state at the end\nof the summer.\n\n> Considering this circumstances I think we should implement the client\n> with the basic commands by reusing git's high level code. I am for building\n> it independently of the git's mainstream.\n\nYeah, I had always assumed it would build independent of git's\nmainstream.\n\n-Peff\n"},{"id":"164924","messageId":"4D963E09.10003@lyx.org","threadId":"26879","inReplyTo":"20110331192758.GD16981@sigill.intra.peff.net","subject":"Re: GSoC questions","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-04-01T21:05:13Z","receivedAt":"2011-04-01T21:05:13Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"\n>> I guess the git2 client will consist solely of non-gitcore code, as\n>> all the gitcore code will be part of libgit2 eventually.\n>>\n> I had sort of assumed that git-core code would be taken as inspiration,\n> but that it would be an entirely new implementation, based around the\n> error handling and build infrastructure provided by libgit2.\n\nLooking at the above, I think we completely agree. When I wrote that the \ngitcore code will get into libgit2, I indeed meant that it should be \nrewritten in the libgit2 style and then be added to libgit2.\n\nThere was also temporarily the idea for GSoC to let Git use the \nlibgit2-library, or maybe to libify git on the road. That's why I \nthought it might be useful if we were not going to rewrite the boring \nadministration code.\n\nThanks for thinking along,\n\nVincent\n"}]}