{"thread":{"id":"26802","subject":"Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","startedAt":"2011-03-20T10:55:31Z","lastAt":"2011-03-23T00:24:11Z","messageCount":13,"participants":["Pavel Raiskup","Shawn Pearce","Junio C Hamano","Vicent Marti","Jeff King","Jonathan Nieder","Vincent van Ravesteijn"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163813","messageId":"op.vsm1yszq2m56ex@localhost.localdomain","threadId":"26802","inReplyTo":null,"subject":"Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Pavel Raiskup","fromEmail":"xraisk00@gmail.com","sentAt":"2011-03-20T10:55:31Z","receivedAt":"2011-03-20T10:55:31Z","isPatch":false,"sender":{"key":"xraisk00@gmail.com","avatar":null},"body":"Hi Git's community!\n\nI'd like to ask you for some details about \"histogram diff\" and \"libgit\"\nenhancement/git-merge tasks for this year's GSOC.\n\nHistogram diff:\nThere is no mentor mentioned in [1]. Does it mean that there is no person\nwho can be a mentor for this task or is that assignment possible to be\nmentored by everyone mentioned in other tasks? I'd like to do this task  \nvery\nmuch. After doing a small observing around source code of git/jgit it looks\nfeasible for me.\nThere is a goal \"Get this feature merged to the upstream git.\" -- but I  \nhave\none theoretical question -- what if the benchmarking/study of histogram  \ndiff\nleads to conclusion that this algorithm will not be useful for upstream?\nDoes it mean \"fail\" in terms of GSOC? I have to think about it even if it\nlooks that there should be speedup quite obvious. I don't want to fail\na priory :).\n\nlibgit2:\nI really like the concept of libraries for to be binding-able from dozens  \nof\nlanguages - this leads to expanding functionality among masses users\nalmost everywhere. In this part I like the idea of implementing new  \nfeatures\ninside library (diff, config file parsing) but also maybe the task of  \nmerging\nlibgit2 into git upstream. Basically I don't know much about that.. and\nyou wrote that this task is more difficult then others, so I probably need\nto study git's and libgit's architecture very precisely beforehand .. but\ncould you tell me some details about that? Is it impossible to do it before\nGSOC deadline and is it worth making a serious big efforts to this task\n(from your point of view onto project objectives)? How big are requirements\nfor this task in term of GSOC?\n\nNow it is quite hectic time because of my study :) it's been a long time\nsince I've had time for myself but I'd like to prepare some patch for to\nproof my interests and abilities.\n\n====\nAnd now not so important part of message (you can skip).. I plan to write\nthis informations later on to google-melange more precisely.\n\nSomething about me || I am:\n-- I like C language but there is no problem to study more deeply other\n    commonly used languages (I need only little brainstorming),\n-- interested in Open Source in general, programming (especially in\n    parallel), chess playing and challenges,\n-- student of master's degree BUT (CZ), penultimate year of study, my last\n    summer :(\n-- a fan of Git because of many reasons, I'd like to become a contributor  \neven\n    if the GSOC opportunity wont come.\n-- not so good English speaker so sometimes my messages could be a little\n    harder to understand.\n\nExperiences:\nIn most cases I have only school projects experiences (even if programming\nprojects are some kind of evergreen here in Brno). But I've had one Open\nSource experience -- enhancement for Daniel Stenberg's libcurl [2] followed\nwith some continuing patches. The main patch implements shell-like wildcard\npattern matching functionality for FTP protocol and makes an enhancement of\nAPI to allow implementing of this functionality among other protocols.\n(I've done implementation of wildcard \"*.txt, [a-z]???.txt\" compiler, auto\ntesting script, enhancement for testing FTP server inside libcurl, man  \npages,\n.. )\nThe most difficult part was to understand how it works inside curl library\n-- but now I think I'm better in that aspect so I think I can make some  \nuseful\nwork for Git too.\n====\n\nDon't worry please, my next messages will be much briefer :)\n\nPavel\n\n[1] https://git.wiki.kernel.org/index.php/SoC2011Ideas\n[2]  \nhttps://github.com/bagder/curl/commit/0825cd80a62c21725fb3615f1fdd3aa6cc5f0f34\n"},{"id":"163830","messageId":"AANLkTi=6z=4m8opfhy9pV1S6ySobSA+WEEESESOJ0MZ4@mail.gmail.com","threadId":"26802","inReplyTo":"op.vsm1yszq2m56ex@localhost.localdomain","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-03-20T18:06:48Z","receivedAt":"2011-03-20T18:06:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Sun, Mar 20, 2011 at 03:55, Pavel Raiskup <xraisk00@gmail.com> wrote:\n> I'd like to ask you for some details about \"histogram diff\" and \"libgit\"\n> enhancement/git-merge tasks for this year's GSOC.\n>\n> Histogram diff:\n> There is no mentor mentioned in [1]. Does it mean that there is no person\n> who can be a mentor for this task or is that assignment possible to be\n> mentored by everyone mentioned in other tasks? I'd like to do this task very\n> much. After doing a small observing around source code of git/jgit it looks\n> feasible for me.\n\nAs the original author of HistogramDiff in JGit, and a contributor to\nC Git... I'm probably the best person to mentor this task. I'm really\nbusy, so I didn't sign up to mentor anything else this year, but I\nthink I would make time for this project.\n\n> There is a goal \"Get this feature merged to the upstream git.\" -- but I have\n> one theoretical question -- what if the benchmarking/study of histogram diff\n> leads to conclusion that this algorithm will not be useful for upstream?\n\nThen the project doesn't merge. :-)\n\n> Does it mean \"fail\" in terms of GSOC? I have to think about it even if it\n> looks that there should be speedup quite obvious. I don't want to fail\n> a priory :).\n\nI don't think so\n\nI think the success of this project is if the code is of the quality\nthat upstream would accept it, and if the final analysis data makes it\nclear whether or not its worth including. Its probably not worth\nincluding if its the same speed as the current Myers diff\nimplementation from libxdiff or slower. But if its 2x faster, its\nprobably worth merging. If the code quality is acceptable to the\nupstream maintainers.\n\n> [1] https://git.wiki.kernel.org/index.php/SoC2011Ideas\n\n-- \nShawn.\n"},{"id":"163831","messageId":"7vhbaxwswo.fsf@alter.siamese.dyndns.org","threadId":"26802","inReplyTo":"op.vsm1yszq2m56ex@localhost.localdomain","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-20T18:25:43Z","receivedAt":"2011-03-20T18:25:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Pavel Raiskup\" <xraisk00@gmail.com> writes:\n\n> I have one theoretical question -- what if the benchmarking/study of\n> histogram diff leads to conclusion that this algorithm will not be\n> useful for upstream?  Does it mean \"fail\" in terms of GSOC?\n\nNot necessarily. A negative result is often as valuable as a positive\nresult.\n\nIt will take a clearly good implementation to justify why a negative\nresult is a success, though. If it is clear to the reviewers that the\nimplementation is poorly done, the negative conclusion does not\nnecessarily mean that use of the histogram algorithm is a bad\napproach---it would just mean the particular implementation that didn't\nimplement it well was, and then the GSoC task may have to be marked as a\nfailure. But otherwise, if the submission is done with the usual code\nquality we would expect from contributors and explained well in its log\nmessage (either positive or negative), I would say it should be considered\na \"success\".\n"},{"id":"163838","messageId":"AANLkTi=Fu5v-5E2dSAA74f0juUQNjNjus5XFWqMb9v9k@mail.gmail.com","threadId":"26802","inReplyTo":"op.vsm1yszq2m56ex@localhost.localdomain","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Vicent Marti","fromEmail":"vicent@github.com","sentAt":"2011-03-20T21:01:25Z","receivedAt":"2011-03-20T21:01:25Z","isPatch":false,"sender":{"key":"vicent@github.com","avatar":"https://gravatar.com/avatar/9d57a2b1e3137bf84342ac1dfdf1cde409b86e8fda5397d05f40f17fa5b84a63?d=mp&s=160"},"body":"Yo!\n\nOn Sun, Mar 20, 2011 at 12:55 PM, Pavel Raiskup <xraisk00@gmail.com> wrote:\n> libgit2:\n> I really like the concept of libraries for to be binding-able from dozens of\n> languages - this leads to expanding functionality among masses users\n> almost everywhere. In this part I like the idea of implementing new features\n> inside library (diff, config file parsing) but also maybe the task of\n> merging\n> libgit2 into git upstream. Basically I don't know much about that.. and\n> you wrote that this task is more difficult then others, so I probably need\n> to study git's and libgit's architecture very precisely beforehand .. but\n> could you tell me some details about that? Is it impossible to do it before\n> GSOC deadline and is it worth making a serious big efforts to this task\n> (from your point of view onto project objectives)? How big are requirements\n> for this task in term of GSOC?\n\nMerging libgit2 into upstream Git is a scary as fuck task. Somebody\nput it up on the Wiki ideas page, but that was not me -- I'm\npersonally doubtful of anybody succeeding on doing that project during\nthe SoC, so I have very little interest on mentoring the task.\n\nHere's what's going on: The Git code base is hairy and not that well\ndocumented, so you're gonna need to study that quite a bit. I like to\nthink that the libgit2 code base is not hairy, and is pretty well\ndocumented (I'm an optimistic guy), but you're still going to need\nquite a bit of research to understand the whole architecture before\nyou can actually merge anything into Git.\n\nYou could try to port just some selected parts of the library to\nlibgit2 (i.e. the parts which benchmark to be faster than their Git\ncounterparts), but the interdependency chain of libgit2 internals is\nnot going to be pretty, embedding into the Git core is not going to be\neasy (libgit2 is reentrant and mostly threadsafe, so there's quite the\narchitecture mismatch there), and there's no guarantee that the final\nimplementation is going to be faster once it's in there.\n\nOverall, you'd need balls of steel and a lot of spare time and\ninterest to accomplish anything significant with this task, so my\npersonal opinion as very old wise man is to forget about it.\n\nHOWEVER. If you want to do something libgit2-related for the SoC\n(which would be awesome), there's still two options:\n\na) Help us make the library more awesome by implementing new features!\nThis task is the opposite the previous one; it's like full of unicorns\nand rainbows. You can choose one (or more) features we are missing,\nand see how to implement them in libgit2 while making them reentrant,\nthreadsafe AND faster. It's not easy, but it's fucking cool. And you\nget to do a lot of micro-optimization if you're into that.\n\nb) Write a minimal Git client using libgit2. Peff keeps bringing this\nup and I think it's a bangin' good idea. Write something small and\n100% self contained in a C executable that runs everywhere with 0\ndependencies -- don't aim for full feature completion, just the basic\nstuff to interoperate with a Git repository. Clone, checkout, branch,\ncommit, push, pull, log. I would totally use that shit on my Windows\nboxes. And since it'll be externally compatible with the original Git\nclient, we can reuse the Git unit tests to test libgit2. HA. Awesome!\n\nSo, yeah. That's pretty much my libgit2-related advice for the SoC.\n\nBest of luck with your application process with whatever project you decide,\nVicent\n"},{"id":"163849","messageId":"20110320234420.GA1919@sigill.intra.peff.net","threadId":"26802","inReplyTo":"AANLkTi=Fu5v-5E2dSAA74f0juUQNjNjus5XFWqMb9v9k@mail.gmail.com","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Jeff King","fromEmail":"peff@github.com","sentAt":"2011-03-20T23:44:20Z","receivedAt":"2011-03-20T23:44:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 20, 2011 at 11:01:25PM +0200, Vicent Marti wrote:\n\n> b) Write a minimal Git client using libgit2. Peff keeps bringing this\n> up and I think it's a bangin' good idea. Write something small and\n> 100% self contained in a C executable that runs everywhere with 0\n> dependencies -- don't aim for full feature completion, just the basic\n> stuff to interoperate with a Git repository. Clone, checkout, branch,\n> commit, push, pull, log. I would totally use that shit on my Windows\n> boxes. And since it'll be externally compatible with the original Git\n> client, we can reuse the Git unit tests to test libgit2. HA. Awesome!\n\nYeah, I would be happy to mentor or co-mentor with Vicent on a project\nlike that. Not only might it be useful to actually _use_, but my secret\nmotive is that I'd like to start testing libgit2 using some of the\nregular git tests, both for interoperability and for performance.\n\n-Peff\n"},{"id":"163854","messageId":"AANLkTimBCH1FhzoUjP-sA2zM2DhVLiPRbLa3JLZg_Ma=@mail.gmail.com","threadId":"26802","inReplyTo":"20110320234420.GA1919@sigill.intra.peff.net","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Vicent Marti","fromEmail":"vicent@github.com","sentAt":"2011-03-21T00:38:17Z","receivedAt":"2011-03-21T00:38:17Z","isPatch":false,"sender":{"key":"vicent@github.com","avatar":"https://gravatar.com/avatar/9d57a2b1e3137bf84342ac1dfdf1cde409b86e8fda5397d05f40f17fa5b84a63?d=mp&s=160"},"body":"On Mon, Mar 21, 2011 at 1:44 AM, Jeff King <peff@github.com> wrote:\n> Yeah, I would be happy to mentor or co-mentor with Vicent on a project\n> like that. Not only might it be useful to actually _use_, but my secret\n> motive is that I'd like to start testing libgit2 using some of the\n> regular git tests, both for interoperability and for performance.\n\nRight on! I've just added this task to the wiki so other prospective\nstudents can take it into account, and listed you as a possible\nmentor.\n\nWhile I'm at it, I removed the \"merge libgit2 into mainstream\" task\nfrom there. Feel free to re-add it again if you find a suitable mentor\n-- I'm getting diarrhea just by thinking about it.\n\nCheers,\nVicent\n"},{"id":"163862","messageId":"20110321012708.GA18323@elie","threadId":"26802","inReplyTo":"AANLkTi=Fu5v-5E2dSAA74f0juUQNjNjus5XFWqMb9v9k@mail.gmail.com","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-21T01:27:08Z","receivedAt":"2011-03-21T01:27:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nVicent Marti wrote:\n\n> Merging libgit2 into upstream Git is a scary as fuck task. Somebody\n> put it up on the Wiki ideas page, but that was not me\n\nCc-ing Ram (who added it), in case he has anything to add.\n\n> -- I'm\n> personally doubtful of anybody succeeding on doing that project during\n> the SoC,\n\nI agree there --- it is a huge task.  But maybe it could inspire\nsomeone to come up with a smaller task.  One long-term goal might be\nto get libgit2 and core git to share revision walking APIs; a baby\nstep towards that would be a proof-of-concept patch to share object\naccess APIs.\n\nIf someone wants to work on this, I'd be glad to talk over what would\nbe needed to make a realistic proposal.\n\n> so I have very little interest on mentoring the task.\n\nThat's okay, of course.  What's probably important for people\nconsidering this project is: would you be willing to answer questions\nand consider patches from a person working on this?  That is, do you\nconsider the goal even worthwhile?\n\nI am probably not the best person to mentor this but if no one else\nwants to then I would be interested.\n\n> Here's what's going on: The Git code base is hairy and not that well\n> documented, so you're gonna need to study that quite a bit. I like to\n> think that the libgit2 code base is not hairy, and is pretty well\n> documented (I'm an optimistic guy), but you're still going to need\n> quite a bit of research to understand the whole architecture before\n> you can actually merge anything into Git.\n\nLike the Linux kernel, the git codebase does not have many comments\nalongside the code, it is true.  But it is actually incredibly well\ndocumented in my experience.  The best documentation is in the\nhistory.  In addition to that, there is some API documentation in\nDocumentation/technical.\n\nA good place to start is the initial commit e83c516 (Initial revision\nof \"git\", the information manager from hell, 2005-04-07).  The\narchitecture described therein is very simple and still exists today\nwith few changes.\n\nTo explain something that has come later, the easiest way is to learn\nhow the author explained it when the change was made.\n\nLet me give an example.  Suppose I am wondering how git decides what\ncommits to show when I say \"git log ^topic1 topic2\".  In particular, I\nwonder what the performance characteristics of that operation are and\nhow it is able to print the first result without spending O(depth of\nhistory) to traverse all the ancestors of topic1 going back to the\nbeginning of time.\n\nFirst step: what does \"git log\" do with that \"^topic1 topic2\"?  Wait,\nwhere is the \"log\" command defined in the first place?\n\n $ git grep -e '\"log\"'\n[...]\n git.c:          { \"log\", cmd_log, RUN_SETUP },\n[...]\n\nOk, it's the cmd_log function.  Looking at the definition of that\nfunction, it seems that it does\n\n\tinit_revisions(&rev, prefix);\n\trev.always_show_header = 1;\n\tmemset(&opt, 0, sizeof(opt));\n\topt.def = \"HEAD\";\n\tcmd_log_init(argc, argv, prefix, &rev, &opt);\n\treturn cmd_log_walk(&rev);\n\n $ git grep -e init_revisions -- Documentation\n Documentation/technical/api-revision-walking.txt:`init_revisions`::\n\nThe revision walking API is explained in the api-revision-walking.txt\ndocument.  From this we learn that responsibility for the revision\nwalk is divided between prepare_revision_walk and get_revision,\ndefined in revision.c.\n\nprepare_revision_walk seems to use functions \"handle_commit\" and\n\"commit_list_insert_by_date\".  What do they do?\n\n $ git log -p -Shandle_commit -- revision.c\n commit cd2bdc5309461034e5cc58e1d3e87535ed9e093b\n Author: Linus Torvalds <torvalds@osdl.org>\n Date:   Fri Apr 14 16:52:13 2006 -0700\n\n     Common option parsing for \"git log --diff\" and friends\n\n     This basically does a few things that are sadly somewhat interdependent,\n[...]\n     Now, that was the easy and straightforward part.\n\n     The slightly more involved part is that some of the programs that want to\n     use the new-and-improved rev_info parsing don't actually want _commits_,\n     they may want tree'ish arguments instead. That meant that I had to change\n     setup_revision() to parse the arguments not into the \"revs->commits\" list,\n     but into the \"revs->pending_objects\" list.\n    \n     Then, when we do \"prepare_revision_walk()\", we walk that list, and create\n     the sorted commit list from there.\n\nOkay: so in revision walking:\n\n - first (in setup_revisions), git pushes the ^topic1 and topic2\n   commits onto a list called \"pending_objects\";\n - next, in prepare_revision_walk, it walks through the pending\n   objects list and inserts them in a commit list, sorted by date;\n\nand next?\n\n $ git log -Sget_revision -- revision.c\n[...]\n commit a4a88b2bab3b6fb0b30f63418701f42388e0fe0a\n Author: Linus Torvalds <torvalds@osdl.org>\n Date:   Tue Feb 28 11:24:00 2006 -0800\n\n     git-rev-list libification: rev-list walking\n\n     This actually moves the \"meat\" of the revision walking from rev-list.c\n     to the new library code in revision.h. It introduces the new functions\n\n         void prepare_revision_walk(struct rev_info *revs);\n         struct commit *get_revision(struct rev_info *revs);\n\n     to prepare and then walk the revisions that we have.\n\n     Signed-off-by: Linus Torvalds <torvalds@osdl.org>\n     Signed-off-by: Junio C Hamano <junkio@cox.net>\n\nWell, that's actually not so helpful.  I mean, it tells us that\nget_revision is what takes care of the revision walk, but it doesn't\ntell us what the revision walk consists of.\n\nSo here we need another trick to get at the meat of the matter ---\nwe need to know where this \"revision walking from rev-list.c\" came\nfrom.  Ah:\n\n $ git log -- rev-list.c\n[...]\n commit 64745109c41a5c4a66b9e3df6bca2fd4abf60d48\n Author: Linus Torvalds <torvalds@ppc970.osdl.org>\n Date:   Sat Apr 23 19:04:40 2005 -0700\n\n     Add \"rev-list\" program that uses the new time-based commit listing.\n\n     This is probably what you'd want to see for \"git log\".\n\nAnd the answer is there in the patch for a commit that comes after that\n(8906300, git-rev-list: use proper lazy reachability analysis,\n2005-05-30).\n\nHeh, probably I didn't choose the best example. :)  A short article\nabout this in Documentation/technical certainly wouldn't be a bad\nthing.\n\nIn addition to \"git log -S\" as used above, I tend to find \"git blame -L\"\nhelpful FWIW.  And people on the list can be helpful, too.\n\n> (libgit2 is reentrant and mostly threadsafe, so there's quite the\n> architecture mismatch there),\n\nCould you expand on that a little?  I understand that a lot of git\ncode wouldn't be usable for libgit2 as-is and that there is going to\nbe some overhead from, say, using malloc to initialize buffers instead\nof relying on static ones.  But does that deserve to be called an\narchitecture mismatch?  Would that make it hard to reuse libgit2 code\nwithin git?\n\nI'd be very interested in learning about more substantial differences\nin approach.  Probably the two codebases could learn a lot from each\nother's design.\n\n> Overall, you'd need balls of steel\n\nHere I agree.\n\n> HOWEVER. If you want to do something libgit2-related for the SoC\n> (which would be awesome), there's still two options:\n>\n> a) Help us make the library more awesome by implementing new features!\n> This task is the opposite the previous one; it's like full of unicorns\n> and rainbows. You can choose one (or more) features we are missing,\n> and see how to implement them in libgit2 while making them reentrant,\n> threadsafe AND faster. It's not easy, but it's fucking cool. And you\n> get to do a lot of micro-optimization if you're into that.\n\nNote that if this is your kind of thing, you might consider sending\n\"libification patches\" to modify the code in git while at it.  That\nmeans free code review and free bugfixes from then on if your changes\nare accepted.\n\n> b) Write a minimal Git client using libgit2. Peff keeps bringing this\n> up and I think it's a bangin' good idea. Write something small and\n> 100% self contained in a C executable that runs everywhere with 0\n> dependencies -- don't aim for full feature completion, just the basic\n> stuff to interoperate with a Git repository.\n\nI agree that this would be very neat, too.\n\n> So, yeah. That's pretty much my libgit2-related advice for the SoC.\n\nThanks again, Vicent, for these very useful explanations.\n\n> Best of luck with your application process with whatever project you decide,\n> Vicent\n\nSeconded. :)\n\nHope that helps,\nJonathan\n"},{"id":"164039","messageId":"op.vsqvsyit2m56ex@localhost.localdomain","threadId":"26802","inReplyTo":"AANLkTi=6z=4m8opfhy9pV1S6ySobSA+WEEESESOJ0MZ4@mail.gmail.com","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Pavel Raiskup","fromEmail":"xraisk00@gmail.com","sentAt":"2011-03-22T12:32:48Z","receivedAt":"2011-03-22T12:32:48Z","isPatch":false,"sender":{"key":"xraisk00@gmail.com","avatar":null},"body":">> Histogram diff:\n>> There is no mentor mentioned in [1]. Does it mean that there is no person\n>> ..\n>\n> As the original author of HistogramDiff in JGit, and a contributor to\n> C Git... I'm probably the best person to mentor this task. I'm really\n> busy, so I didn't sign up to mentor anything else this year, but I\n> think I would make time for this project.\n\nThanks for your answer and for your ability to be a mentor of this task.\n\n>> There is a goal \"Get this feature merged to the upstream git.\" -- but I have\n>> one theoretical question -- what if the benchmarking/study of histogram diff\n>> leads to conclusion that this algorithm will not be useful for upstream?\n>\n> Then the project doesn't merge. :-)\n>\n>> Does it mean \"fail\" in terms of GSOC? I have to think about it even if it\n>> looks that there should be speedup quite obvious. I don't want to fail\n>> a priory :).\n>\n> I don't think so\n>\n> I think the success of this project is if the code is of the quality\n> that upstream would accept it, and if the final analysis data makes it\n> clear whether or not its worth including. Its probably not worth\n> including if its the same speed as the current Myers diff\n> implementation from libxdiff or slower. But if its 2x faster, its\n> probably worth merging. If the code quality is acceptable to the\n> upstream maintainers.\n\nI wanted to know exactly this kind of information. Of course\nI don't want to make a code of unacceptable quality from any perspective.\n\nAnd I think that you probably don't expect histogram diff to be significantly\nfaster in general :)\n\nThanks again - it is good to know that you as author of histogram diff are\nhere. And sorry for my latency ..\n[ot] this is because of hectic school schedule now - which is actually not\ngood :( I need to study git source very deeply _NOW_ (I wanted to reply\nearlier but..) [/ot]\n\nThanks to Junio C Hamano with almost the same answer here:\nhttp://thread.gmane.org/gmane.comp.version-control.git/169498/focus=169516\n\nPavel\n\n>> [1] https://git.wiki.kernel.org/index.php/SoC2011Ideas\n"},{"id":"164061","messageId":"op.vsq7e4og2m56ex@localhost.localdomain","threadId":"26802","inReplyTo":"20110321012708.GA18323@elie","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Pavel Raiskup","fromEmail":"xraisk00@gmail.com","sentAt":"2011-03-22T16:43:42Z","receivedAt":"2011-03-22T16:43:42Z","isPatch":false,"sender":{"key":"xraisk00@gmail.com","avatar":null},"body":"Hello,\n\nJonathan Nieder wrote:\n\n> Vicent Marti wrote:\n>\n>> -- I'm\n>> personally doubtful of anybody succeeding on doing that project during\n>> the SoC,\n>\n> ...\n> If someone wants to work on this, I'd be glad to talk over what would\n> be needed to make a realistic proposal.\n>\n>> so I have very little interest on mentoring the task.\n>\n> That's okay, of course.  What's probably important for people\n> considering this project is: would you be willing to answer questions\n> and consider patches from a person working on this?  That is, do you\n> consider the goal even worthwhile?\n>\n> I am probably not the best person to mentor this but if no one else\n> wants to then I would be interested.\n\nAs I can see now, it could be quite too heavy for me to produce\nresults as good as would be needed. This is probably quite difficult\ntask for starting with git contributing. Rather considering the other\ngit-topics for now (but I'm not rejecting this idea yet).\n\n> A good place to start is the initial commit e83c516 (Initial revision\n> of \"git\", the information manager from hell, 2005-04-07).\n> ........\n> Heh, probably I didn't choose the best example. :)  A short article\n> about this in Documentation/technical certainly wouldn't be a bad\n> thing.\n>\n> In addition to \"git log -S\" as used above, I tend to find \"git blame -L\"\n> helpful FWIW.  And people on the list can be helpful, too.\n\nThis \"short\" article is very helpful, thank you for that! I think\nit can help all contributors (not only students) at the beginning\nof their git journey.\n\n>> b) Write a minimal Git client using libgit2. Peff keeps bringing this\n>> up and I think it's a bangin' good idea. Write something small and\n>> 100% self contained in a C executable that runs everywhere with 0\n>> dependencies -- don't aim for full feature completion, just the basic\n>> stuff to interoperate with a Git repository.\n>\n> I agree that this would be very neat, too.\n\nThe idea of git client based on libgit2 sounds VERY interesting. I'm\ngoing to ask for some details in neighboring sub-thread.\n\n>> Best of luck with your application process with whatever project you decide,\n>> Vicent\n>\n> Seconded. :)\n\nThank you both, I'm not going to try other projects, there is not enough\ntime now for researching other projects and git is my only choice and desire.\n\nPavel\n"},{"id":"164064","messageId":"op.vsq9o4mz2m56ex@localhost.localdomain","threadId":"26802","inReplyTo":"20110320234420.GA1919@sigill.intra.peff.net","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Pavel Raiskup","fromEmail":"xraisk00@gmail.com","sentAt":"2011-03-22T17:32:54Z","receivedAt":"2011-03-22T17:32:54Z","isPatch":false,"sender":{"key":"xraisk00@gmail.com","avatar":null},"body":"Hi again!\n\nThis sounds probably like the most exciting task for me:\n\n>> b) Write a minimal Git client using libgit2. Peff keeps bringing this\n>> up and I think it's a bangin' good idea. Write something small and\n>> 100% self contained in a C executable that runs everywhere with 0\n>> dependencies -- don't aim for full feature completion, just the basic\n>> stuff to interoperate with a Git repository. Clone, checkout, branch,\n>> commit, push, pull, log. I would totally use that shit on my Windows\n>> boxes. And since it'll be externally compatible with the original Git\n>> client, we can reuse the Git unit tests to test libgit2. HA. Awesome!\n>\n> Yeah, I would be happy to mentor or co-mentor with Vicent on a project\n> like that. Not only might it be useful to actually _use_, but my secret\n> motive is that I'd like to start testing libgit2 using some of the\n> regular git tests, both for interoperability and for performance.\n\nDo you mean git tests in directory \"/t\"?\n\nCould you give me a list of possible reusable unit tests? After a quick\noverview of test suite in git it looks quite complex to reuse. I haven't\nspent a lot of time studying test-suite, but calling:\n\ntest_expect_success 'plain' 'command && command && ..'\n\nreinterprets chain of commands given in (2nd) string and in this\ncommands is often called git as utility with arguments. Even in this\nvery easy test feature is expected some command-line-interface behavior\n from tested utility.. Is this the way how do you want to test this new\nlibgit2-like tool? So this standalone utility is going to have the\nsame interface as git has -- kind of substitution of git with \"git2\"\ninside test suite?\n\nThis probably will lead to some test suite changes, is it truth?\n"},{"id":"164075","messageId":"20110322184737.GB22534@sigill.intra.peff.net","threadId":"26802","inReplyTo":"op.vsq9o4mz2m56ex@localhost.localdomain","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Jeff King","fromEmail":"peff@github.com","sentAt":"2011-03-22T18:47:37Z","receivedAt":"2011-03-22T18:47:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 22, 2011 at 06:32:54PM +0100, Pavel Raiskup wrote:\n\n> >Yeah, I would be happy to mentor or co-mentor with Vicent on a project\n> >like that. Not only might it be useful to actually _use_, but my secret\n> >motive is that I'd like to start testing libgit2 using some of the\n> >regular git tests, both for interoperability and for performance.\n> \n> Do you mean git tests in directory \"/t\"?\n\nYes.\n\n> Could you give me a list of possible reusable unit tests? After a quick\n> overview of test suite in git it looks quite complex to reuse. I haven't\n> spent a lot of time studying test-suite, but calling:\n> \n> test_expect_success 'plain' 'command && command && ..'\n> \n> reinterprets chain of commands given in (2nd) string and in this\n> commands is often called git as utility with arguments. Even in this\n> very easy test feature is expected some command-line-interface behavior\n> from tested utility.. Is this the way how do you want to test this new\n> libgit2-like tool? So this standalone utility is going to have the\n> same interface as git has -- kind of substitution of git with \"git2\"\n> inside test suite?\n\nExactly. My plan was to implement a few of the simpler git commands (or\nat least the basic parts of them) using libgit2, and then test them with\nunmodified scripts from git's t/ directory.\n\nOf course, many of the tests won't pass because of obscure features that\nwe haven't implemented. But that's OK. Even getting a partial list of\npassing tests will be useful. And tests known not to work because of\nunimplemented features can often be skipped (see the description of\nGIT_SKIP_TESTS in t/README). Part of the project would be sorting out\nwhich tests will be useful.\n\nIt may also be necessary to use a mixture of git and libgit2 commands to\nfinish tests. For example, a test which is really about checking \"log\"\nmight use \"commit\", but \"commit\" hasn't been implemented yet. But it is\nstill useful information if we cheat and use regular git's \"commit\", but\ntest the libgit2 log command.\n\nAs far as which commands to start with, I would start with plumbing\ncommands like \"update-index\", \"commit-tree\", \"update-ref\", \"rev-list\",\netc.  Those are basic building blocks that have reasonably simple\ninterfaces, and they're easy to test. And once you start, I think it\nwill become more obvious where to go next (because some of the commands\nbuild on the results of others).\n\n> This probably will lead to some test suite changes, is it truth?\n\nThere may be modifications necessary to the test suite to make this\neasier to do. But rather than forking the test suite and changing the\ntests, I would much rather see whatever support is needed done in a\ngeneralized way and merged to regular git.\n\n-Peff\n"},{"id":"164079","messageId":"7vtyevj753.fsf@alter.siamese.dyndns.org","threadId":"26802","inReplyTo":"20110322184737.GB22534@sigill.intra.peff.net","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-22T19:18:48Z","receivedAt":"2011-03-22T19:18:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@github.com> writes:\n\n> It may also be necessary to use a mixture of git and libgit2 commands to\n> finish tests. For example, a test which is really about checking \"log\"\n> might use \"commit\", but \"commit\" hasn't been implemented yet. But it is\n> still useful information if we cheat and use regular git's \"commit\", but\n> test the libgit2 log command.\n\nAbsolutely, and I don't even think that is \"cheating\"; it is merely a\nnatural way to work incrementally.\n\n> As far as which commands to start with, I would start with plumbing\n> commands like \"update-index\", \"commit-tree\", \"update-ref\", \"rev-list\",\n> etc.  Those are basic building blocks that have reasonably simple\n> interfaces, and they're easy to test. And once you start, I think it\n> will become more obvious where to go next (because some of the commands\n> build on the results of others).\n>\n>> This probably will lead to some test suite changes, is it truth?\n\nSome tests _might_ depend on implementation detail that we would rather\nnot, but I don't think there are too many of them, unless you count the\nstuff that use \"test-<something>\" helper binary that link with libgit.a to\nmake direct calls to the internal.  I would suggest to consider a failure\nan uncovered bug in the new implementation by default, and discuss the\ntests that do depend on the implementation detail of C git on case-by-case\nbasis to be fixed.\n"},{"id":"164102","messageId":"4D893DAB.3000501@lyx.org","threadId":"26802","inReplyTo":"AANLkTi=Fu5v-5E2dSAA74f0juUQNjNjus5XFWqMb9v9k@mail.gmail.com","subject":"Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-03-23T00:24:11Z","receivedAt":"2011-03-23T00:24:11Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"\n> b) Write a minimal Git client using libgit2. Peff keeps bringing this\n> up and I think it's a bangin' good idea. Write something small and\n> 100% self contained in a C executable that runs everywhere with 0\n> dependencies -- don't aim for full feature completion, just the basic\n> stuff to interoperate with a Git repository. Clone, checkout, branch,\n> commit, push, pull, log. I would totally use that shit on my Windows\n> boxes. And since it'll be externally compatible with the original Git\n> client, we can reuse the Git unit tests to test libgit2. HA. Awesome!\n>\n\nI would dream of having a platform-independent GUI based on libgit2 \nwhich could be used to manage a large project. Setup the workflow in the \napp, requiring only single  mouseclicks to promote a topic branch into \nthe stable series. Have a button to merge all maint-branch-updates into \nthe other branches. And more..\n\nIn order to come up with a possible workflow for our project, I have \nbeen checking out how Git is managed. I got a little bit disappointed \nthat Junio uses some 'home-brewn' scripts for Git. I don't want to write \nthem myselves (on Windows).\n\nI'm happy to see that the 'vger' people are supporting libgit2.\n\nAnyway, when I do have some time, I am willing to contribute to the \nlibgit2 project.\n\nGreetings,\n\nVincent\n"}]}