{"thread":{"id":"26867","subject":"start of git2 (based on libgit2)","startedAt":"2011-03-25T23:12:03Z","lastAt":"2011-03-27T09:56:04Z","messageCount":7,"participants":["Motiejus Jakštys","Vincent van Ravesteijn","Sam Vilain","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164341","messageId":"20110325231203.GA7961@jakstys.lt","threadId":"26867","inReplyTo":null,"subject":"start of git2 (based on libgit2)","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-03-25T23:12:03Z","receivedAt":"2011-03-25T23:12:03Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"Hello,\n\nI wrote similar letter before, but did not receive feedback I was expecting.\n\nI think libgit2 is an amazing thing, and I started writing[1] cli client for\nit. This is what it can do now:\n    $ git2 rev-list <anything>\n\nWhich is roughly equivalent to:\n    $ git rev-list HEAD\n\nI do not know how it will figure out past merge history, but that's for\nthe future.\n\nI want to get started with it, but before that I want and discuss some\narchitectural questions.\n\nAccording to Jeff King[2], I should start with plumbing commands. I\nagree.  However, how deep?  I.e. do I have to make sure all git rev-list\npossible arguments are implemented?\n\nAre we aiming for a distributed 100s of executables architecture\n(current git), or single huge binary? I would go for single executable\nfor to higher portability. Is that ok?\n\nBuild tool. Currently libgit2 uses waf. I am not against it (I've chosen\nwaf for one of my own C++ projects), However, it's too clumsy for me. Is\nit me who lacks experience? Scons looks much easier for me. Moreover, we\ndo not need automatic configuration, so it makes waf \"overfeatured\".\n\nBuild configuration. Git-send-email is not really a must-have for an\nembedded device, so we should be able to specify these features in\nconfigure-time. How do you think it should be taken care of?\n\n1) <buildtool> configure  --disable-everything --enable-email\n2) make menuconfig and enjoy the blue screen of choice\n3) anything else?\n\nWaiting for your answers, will go on working.\n\nI am a student and would like to do this take this up in GSOC. I just\nreceived a letter from Vicent Marti with sort of confirmation that the\nproject is interesting for the community. I'm happy about it.  Currently\nI am a full-time python programmer, but have done some C++. I created\nSoundPatty[3], a real-time sound recognition (record) application for my\njob VoIP recognition needs.\n\nIn case you have any questions, opinions, please ask. Thank you.\n\n[1] https://github.com/Motiejus/git2/\n[2] http://marc.info/?l=3Dgit&m=3D130081966214059&w=3D4\n[3] https://github.com/Motiejus/SoundPatty/ \n[CV] http://m.jakstys.lt/\n\nMotiejus Jakštys\n"},{"id":"164343","messageId":"4D8D2B31.4040908@lyx.org","threadId":"26867","inReplyTo":"20110325231203.GA7961@jakstys.lt","subject":"Re: start of git2 (based on libgit2)","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-03-25T23:54:25Z","receivedAt":"2011-03-25T23:54:25Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"On 26-3-2011 0:12, Motiejus Jakštys wrote:\n> Hello,\n>\n> I wrote similar letter before, but did not receive feedback I was expecting.\n\nI wrote a mail on the same topic to the libgit2@librelist.org \nmailinglist, because I got interested in the same project (although I \nwill not be a GSoC student).\n\nhttp://librelist.com/browser/libgit2/\n> According to Jeff King[2], I should start with plumbing commands. I\n> agree.  However, how deep?  I.e. do I have to make sure all git rev-list\n> possible arguments are implemented?\n\nI guess a lot can be copied from Git itself. Actually builtin/rev-list.c \nconsists mostly of command line arguments parsing methods, and \noutputting functions. The key is to parse what you want to know and ask \nlibgit2 to provide the info. If libgit2 has implemented the basic \nfunctionality that is needed, the rest would be relatively simple.\n\n> Are we aiming for a distributed 100s of executables architecture\n> (current git), or single huge binary? I would go for single executable\n> for to higher portability. Is that ok?\n\nAFAICS, current git is a single binary on Windows already.\n\n> Build tool. Currently libgit2 uses waf. I am not against it (I've chosen\n> waf for one of my own C++ projects), However, it's too clumsy for me. Is\n> it me who lacks experience? Scons looks much easier for me. Moreover, we\n> do not need automatic configuration, so it makes waf \"overfeatured\".\n\nWhy not CMake which is also used for libgit2 ?\n\nI already wrote a CMakeLists file for your git2 app.\n\n> I am a student and would like to do this take this up in GSOC. I just\n> received a letter from Vicent Marti with sort of confirmation that the\n> project is interesting for the community.\n\nAs you know, this project can be possibly fulfilled by a GSoC student \n(either you or someone else). Maybe people are awaiting this before \ndiving into the project.\n\nVincent\n"},{"id":"164346","messageId":"20110326021300.GC2934@jakstys.lt","threadId":"26867","inReplyTo":"4D8D2B31.4040908@lyx.org","subject":"Re: start of git2 (based on libgit2)","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-03-26T02:13:01Z","receivedAt":"2011-03-26T02:13:01Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Sat, Mar 26, 2011 at 12:54:25AM +0100, Vincent van Ravesteijn wrote:\n> On 26-3-2011 0:12, Motiejus Jakštys wrote:\n> >According to Jeff King[2], I should start with plumbing commands. I\n> >agree.  However, how deep?  I.e. do I have to make sure all git rev-list\n> >possible arguments are implemented?\n> \n> I guess a lot can be copied from Git itself. Actually\n> builtin/rev-list.c consists mostly of command line arguments parsing\n> methods, and outputting functions. The key is to parse what you want\n> to know and ask libgit2 to provide the info. If libgit2 has\n> implemented the basic functionality that is needed, the rest would\n> be relatively simple.\n> AFAICS, current git is a single binary on Windows already.\n\nSo I have the answer. Thank you. Further working path is getting\nclearer. Finish with rev-list, make it work with t/. Then pick up\ndependencies of one of the must-have commands (commit/merge/diff?),\nimplement them and implement the command.\n\n> \n> >Build tool. Currently libgit2 uses waf. I am not against it (I've chosen\n> >waf for one of my own C++ projects), However, it's too clumsy for me. Is\n> >it me who lacks experience? Scons looks much easier for me. Moreover, we\n> >do not need automatic configuration, so it makes waf \"overfeatured\".\n> \n> Why not CMake which is also used for libgit2 ?\n\nDid not notice that. I noticed wscript and stopped looking... I never\ntried CMake before. But I have nothing against it.\n\n> \n> I already wrote a CMakeLists file for your git2 app.\n\nVery nice. Pull request? Patch?\n\n> \n> As you know, this project can be possibly fulfilled by a GSoC\n> student (either you or someone else). Maybe people are awaiting this\n> before diving into the project.\n\nCompetition is a good thing. The most important thing is picking the\nbest choice.\n\nThank you Vincent,\nMotiejus\n"},{"id":"164349","messageId":"4D8D88AF.9010306@vilain.net","threadId":"26867","inReplyTo":"20110325231203.GA7961@jakstys.lt","subject":"Re: start of git2 (based on libgit2)","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2011-03-26T06:33:19Z","receivedAt":"2011-03-26T06:33:19Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On 26/03/11 12:12, Motiejus Jakštys wrote:\n> Build tool. Currently libgit2 uses waf. I am not against it (I've chosen\n> waf for one of my own C++ projects), However, it's too clumsy for me. Is\n> it me who lacks experience? Scons looks much easier for me. Moreover, we\n> do not need automatic configuration, so it makes waf \"overfeatured\".\n\nAnother one you might like to look at is \"ccanlint\" - it wraps a whole\nbunch of things that make for exceptional quality code, such as code\ncoverage by the test suite, documentation coverage, compilable examples,\neven cranks it up using valgrind to check that it's right.\n\nAs far as your question about how much to implement or bring across from\ngit - try to do it feature by feature, with reference to the test suite\nand make sure each feature has a test.  It's a very bad idea IMHO to\nport across untested features.  I'd much rather have a core set of\ncommands which are well tested and stable, than a handful of\nfully-implemented but buggy commands.\n\nSam\n"},{"id":"164361","messageId":"20110326132915.GA2859@sigill.intra.peff.net","threadId":"26867","inReplyTo":"4D8D2B31.4040908@lyx.org","subject":"Re: start of git2 (based on libgit2)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-26T13:29:15Z","receivedAt":"2011-03-26T13:29:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 26, 2011 at 12:54:25AM +0100, Vincent van Ravesteijn wrote:\n\n> http://librelist.com/browser/libgit2/\n> >According to Jeff King[2], I should start with plumbing commands. I\n> >agree.  However, how deep?  I.e. do I have to make sure all git rev-list\n> >possible arguments are implemented?\n> \n> I guess a lot can be copied from Git itself. Actually\n> builtin/rev-list.c consists mostly of command line arguments parsing\n> methods, and outputting functions. The key is to parse what you want\n> to know and ask libgit2 to provide the info. If libgit2 has\n> implemented the basic functionality that is needed, the rest would be\n> relatively simple.\n\nI wouldn't worry about having _every_ argument. Some arguments are much\nless frequently used than others. For example, start with basic stuff,\nlike including and excluding commits (e.g., \"branch1 ^branch2\"),\n--max-count, --{min,max}-age, --grep, and others. Do common things like\npath limiting. And then once all that is done and tested, start worrying\nabout things like --cherry-pick (or maybe not, and focus on the basics\nof other simple commands).\n\n> >Are we aiming for a distributed 100s of executables architecture\n> >(current git), or single huge binary? I would go for single executable\n> >for to higher portability. Is that ok?\n> \n> AFAICS, current git is a single binary on Windows already.\n\nEven on Linux, most of the commands are just hardlinks to the git\nexecutable. Most commands are built-in these days. A few are still\nexternal but written in C (sometimes because we want to keep them small\nand external, like git-daemon and git-shell). But there are still some\ncommands written in other languages, like pull, stash, and\nadd--interactive.\n\nCheck out the BUILTIN_OBJS, PROGRAM_OBJS, and SCRIPT_* variables in the\nMakefile.\n\nSo yeah, for basic commands, one monolithic binary is probably fine.\n\n-Peff\n"},{"id":"164385","messageId":"7v62r52c85.fsf@alter.siamese.dyndns.org","threadId":"26867","inReplyTo":"20110326132915.GA2859@sigill.intra.peff.net","subject":"Re: start of git2 (based on libgit2)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-27T08:34:34Z","receivedAt":"2011-03-27T08:34:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sat, Mar 26, 2011 at 12:54:25AM +0100, Vincent van Ravesteijn wrote:\n>> \n>> I guess a lot can be copied from Git itself. Actually\n>> builtin/rev-list.c consists mostly of command line arguments parsing\n>> methods, and outputting functions. The key is to parse what you want\n>> to know and ask libgit2 to provide the info. If libgit2 has\n>> implemented the basic functionality that is needed, the rest would be\n>> relatively simple.\n>\n> I wouldn't worry about having _every_ argument. Some arguments are much\n> less frequently used than others. For example, start with basic stuff,\n> like including and excluding commits (e.g., \"branch1 ^branch2\"),\n> --max-count, --{min,max}-age, --grep, and others. Do common things like\n> path limiting. And then once all that is done and tested, start worrying\n> about things like --cherry-pick (or maybe not, and focus on the basics\n> of other simple commands).\n\nI agree that for a summer student project, aiming at basic stuff makes\nmore sense than trying to chew a large bite that cannot be managed within\nthe timeframe and not achieving anything.\n\n\"A..B\" requires you to walk the ancestry chain. Limiting history with\npathspec while simplifying merges needs to use the tree-diff machinery;\nand filtering commits by looking at the message with \"--grep\" needs to\ncall into the grep machinery.  Depending on how much libgit2 has already\ncovered the basic blocks, even the above list might be too much, I am\nafraid.\n\nA good news is that among the larger and more important basic building\nblocks in C git, there is only one part that was designed from day one to\ndisregard the reusability and instead aimed for speed and simplicity, and\nthat is the history and object walking. The way the in-core object pool is\nmanaged and especially the way per-object flags are designed to be used\nclearly show that the revision walker machinery can take it granted that\nthe calling programs are run-once-and-clean-via-exit.\n\nBut other major parts are designed to be reusable and I would imagine that\nit shouldn't be hard to link with them (or better yet, find counterparts\nin libgit2). \"diff\" machinery below the diffcore layer (i.e. the entry\npoints \"diff-lib.c\" calls into, e.g. starting at diff_addremove(), then\nrunning the diffcore machinery with diffcore_std() and finally getting the\nresult from diff_flush() callchain) and \"grep\" machinery below the\n\"grep.c\" (but not \"builtin/grep.c\") are designed not to depend on the\nprocess level global variables.\n"},{"id":"164388","messageId":"4D8F09B4.7030602@lyx.org","threadId":"26867","inReplyTo":"7v62r52c85.fsf@alter.siamese.dyndns.org","subject":"Re: start of git2 (based on libgit2)","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-03-27T09:56:04Z","receivedAt":"2011-03-27T09:56:04Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"> I agree that for a summer student project, aiming at basic stuff makes\n> more sense than trying to chew a large bite that cannot be managed within\n> the timeframe and not achieving anything\n\nIf things will be working out, I will at least not disappear after the \nsummer. I'm quite new here, but I'd like to help out in coordinating the \nstudent(s) and to continue with it after summer (if the student(s) do \nnot stick to the git development). I'm still missing quite some \nknowledge about git, but I hope that will come with time.\n\n> \"A..B\" requires you to walk the ancestry chain. Limiting history with\n> pathspec while simplifying merges needs to use the tree-diff machinery;\n> and filtering commits by looking at the message with \"--grep\" needs to\n> call into the grep machinery.  Depending on how much libgit2 has already\n> covered the basic blocks, even the above list might be too much, I am\n> afraid.\n\nYes, it would be important to understand how much already is covered by \nlibgit2. If someone could shed some light on this (see also my message \non the libgit2@librelist.org mailing list).\n\n> A good news is\n\n[..] still re-reading this paragraph to find out what the actual 'good' \npart of this news is ;)...[..]\n\n> that among the larger and more important basic building\n> blocks in C git, there is only one part that was designed from day one to\n> disregard the reusability and instead aimed for speed and simplicity, and\n> that is the history and object walking. The way the in-core object pool is\n> managed and especially the way per-object flags are designed to be used\n> clearly show that the revision walker machinery can take it granted that\n> the calling programs are run-once-and-clean-via-exit.\n\nThat's what I meant with my previous message. I was not aiming to \nimplement all exotic features, but I think that it would be a good \ndesign if git and git2 share a lot together and only differ in how they \nactually use the git/libgit backend. As part of the process, the git \ncode can be adjusted as well to \"libify\" it (as it was called in another \nthread).\n\nVincent\n"}]}