{"thread":{"id":"41802","subject":"GSoC 2016 | Proposal | Incremental Rewrite of git bisect","startedAt":"2016-03-23T23:27:12Z","lastAt":"2016-03-25T11:43:58Z","messageCount":8,"participants":["Pranit Bauva","Christian Couder","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281624","messageId":"CAFZEwPNXKo5YN9OPPCkO90bSPD3ittU+y8eDxh-JLxnihBznuw@mail.gmail.com","threadId":"41802","inReplyTo":null,"subject":"GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-23T23:27:12Z","receivedAt":"2016-03-23T23:27:12Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"Hey!\n\nI have prepared a proposal for Google Summer of Code 2016. I know this\nis a bit late, but please try to give your comments and suggestions.\nMy proposal could greatly improve from this. Some questions:\n\n1. Should I include more ways in which it can help windows?\n2. Should I include the function names I intend to convert?\n3. Is my timeline (a bit different) going to affect me in any way?\n\nHere is a Google doc for my proposal.\nhttps://docs.google.com/document/d/1stnDPA5Hs3u0a8sqoWZicTFpCz1wHP9bkifcKY13Ocw/edit?usp=sharing\n\nFor the people who prefer the text only version :\n\n-----------------------------------------------------------------------------------\n\nIncremental rewrite of Git bisect\n\nAbout Me\n\nBasic Information\n\n\nName           Pranit Bauva\n\nUniversity     IIT Kharagpur\n\nMajor            Mining Engineering\n\nEmail            pranit.bauva@gmail.com\n\nIRC              pungi-man\n\nBlog             http://bauva.in\n\nTimezone     IST (UTC +5:30)\n\nBackground\n\nI am a first year undergraduate in the department of Mining\nEngineering at Indian Institute of Technology, Kharagpur. I am an open\nsource enthusiast. I am a part of Kharagpur Linux Users Group which is\nbasically a group of open-source enthusiasts. I am quite familiar with\nC and I have been using shell for some time now and still find new\nthings about it everyday. I have used SVN when I was on Windows and\nthen I switched to Git when I moved to linux. Git seems like magic. I\nalways wanted to involve in the development process and Google Summer\nof Code is an a awesome way to achieve it.\n\n\nAbstract\n\nGit bisect is a frequently used command which helps the developers in\nfinding the commit which introduced the bug. Some part of it is\nwritten in shell script. I intend to convert it to low level C code\nthus making them builtins. This will increase Git’s portability.\nEfficiency of git bisect will definitely increase but it would not\nreally matter much as most of the time is consumed in compiling or\ntesting when in bisection mode but it will definitely reduce the\noverhead IO which can make the heavy process of compiling relatively\nlighter.\n\n\nProblems Shell creates\n\nSystem Dependencies\n\nUsing shell code introduces various dependencies even though they\nallowing prototyping of the code quickly. Shell script often use some\nPOSIX utilities like cat, grep, ls, mkdir, etc which are not included\nin non-POSIX systems by default. These scripts do not have access to\nthe git’s internal low level API. So even trivial tasks have to be\nperformed by spawning new process every time. So when git is ported to\nwindows, it has to include all the utilities (namely a shell\ninterpreter, perl bindings and much more).\n\nScripts introduce extra overheads\n\nShell scripts do not have access to Git’s internal API which has\nexcellent use of cache thus reducing the unnecessary IO of user\nconfiguration files, repository index and filesystem access. By using\na builtin we could exploit the cache system thus reducing the\noverhead. As compiling / testing already involves quite a number of\nresources, it would be good if we could do our best to make more\nresources available for that.\n\nPotential Problems\n\nRewriting may introduce bugs\n\nRewriting the shell script to C might introduce some bugs. This\nproblem will be properly taken care of in my method of approach\n(described below). Still this approach will definitely not guarantee\nthat the functionality of the new will be exactly similar to the old\none, though it will greatly reduce its possibility. The reviews\nprovided by the seniors in the git community would help a lot in\nreducing bugs since they know the common bugs and how to work around\nthem. The test suite of git is quite nice which has an awesome\ncoverage.\n\nRewritten can be hard to understand\n\nGit does not like having many external dependencies, libraries or\nexecutables other than what is provided by git itself and the\nrewritten code should follow this. C does not provide with a lot of\nother facilities like text processing which shell does whose C\nimplementation often spans to multiple lines. C is also notorious for\nbeing a bit “cryptic”. This problem can be compensated by having well\nwritten documentation with well defined inputs, outputs and behavior.\n\nA peek into git bisect\n\nHow does it help?\n\nGit bisect helps the software developers to find the commit that\nintroduced a regression. Software developers are interested in knowing\nthis because a commit changes a small set of code (most time).  It is\nmuch easier to understand and fix a problem when you know only need to\ncheck a very small set of changes, than when you don’t know where to\nlook at it. It is not that the problem will be exactly in that commit\nbut it will be related to the behavior introduced in the commit.\nSoftware bugs can be a nightmare when the code base is very large.\nThere would be a lot of sleepless night in figuring out the part which\ncauses the error. This is where git bisect helps. This is the one of\nthe most sought after tool in software development.\n\nGit bisect algorithm (short description)\n\nGit’s commits form a directed acyclic graph (DAG) which makes it a bit\ndifficult to find the bisection commit. The algorithm it uses is :\n\nStep 1: Keeps only the ancestors of “bad” commit (including “bad” one)\nand the commits that are not the ancestors of “good” commit (excluding\n“good” one). This helps in reducing a lot of “interesting” commits.\n\nStep 2: Starting from the good ends (or end), associate some kind of\n“weight” which depends on its distance from the good commit also\nconsidering some other factors.\n\nStep 3: Find the midpoint of the max weight which will be the bisection commit.\n\nStep 4: Repeat Step 1 but now with one more “good” commit which will\ncause rearranging of “weights” thus finishing the algorithm which uses\nbinary search.\n\nFurther details about the algorithm can be found in this article\nwritten by Christian Couder.\n\nCurrent status of git bisect\n\nThe bisect code is currently spread across multiple files namely\ngit-bisect.sh, bisect.c, bisect.h, and bisect--helper.c . The\nalgorithmic part is written in bisect.c . git-bisect.sh acts like a\nglue connecting parts of bisect.c with git-rev-list (which helps in\nlisting the commits in various types and formats), git-rev-parse\n(which helps in knowing the SHA-1 checksum for the ref passed),\ngit-symbolic-refs (to read, modify and delete symbolic refs),\ngit-show-branch (which helps by showing the branches and their\nrespective commits), git-update-ref (to safely update the SHA-1\nchecksum stored in a ref safely), git-for-each-ref (to get information\non each ref with given pattern, format, keys and much more) and\ngit-check-ref-format (to check whether the ref has a proper format and\ndoesn’t contain some “special” characters which aren’t allowed) though\nthis is soon going to be replaced by using a sub command\n`--check-term-format` of bisect--helper whose patch is in its final\nstages. git-bisect.sh is responsible for writing the respective data\nconcerning the status on bisect to the various files namely\nBISECT_LOG, BISECT_NAMES, BISECT_START, BISECT_ANCESTORS_OK,\nBISECT_LOG, refs/bisect and those which would be included in the\ndirectory once bisection moves further.\n\nHow will I go about with this project?\n\nUnderstand related areas\n\nIn the start, I will focus on understanding the things that\ngit-bisect.sh depends on. I will try to debug that part of code and\nunderstand it through documentation. I will also learn to use some\nmore parts of API which I am currently unfamiliar with concerning this\nproject. I will also gain more familiarity with running gdb sessions\nfor big projects.\n\nDiscussion about the future look of bisect\n\nWhen converting from shell to C, there needs to be quite some amount\nof changes rather than just plainly translating the code. This is the\npart where I will discuss with the git community as to what parts they\nwish they could change it or which are better changed in C. Since C\nand shell are quite different, approaches which seem good in shell are\nnot that good in C and vice versa. So having a thorough discussion can\nreally help.\n\nConvert each function individually\n\nThen I will convert each function from shell script to a C builtin in\nbisect--helper.c individually. This raises a very valid questions as\nto how to test whether the function performs the tasks as intended\nsince tests suites are written for git-bisect.sh and not\nbisect--helper.c . To take care for this problem, I will first convert\neach function to its C builtin and then provide utility in\nbisect--helper.c so that git-bisect.sh can easily communicate with it.\nIn this way, I can make sure that git-bisect.sh uses a corresponding C\nbuiltin rather than origin shell function to run the tests which will\nhelp in recognising for any errors (if any) which the patch can have.\nTo help git-bisect.sh communicate, I will make the functions as sub\ncommands in bisect--helper.c so I can ensure that bisect--helper can\nreact in a way which is independant of other sub commands.\n\nUnification of bisect.c and bisect--helper.c\n\nThis will unify the algorithmic and non-algorithmic parts of bisect\nbringing them under one heading to make the code clean.\n\nThorough testing of bisect\n\nThis will be dedicated for thorough deep testing for any problems\nwhich crept in after the shell to C conversion. I will also aim to\ninclude some more tests to improve coverage of bisect. If time\npersists, I will dig further in examining the failing tests and try\nand fix the bugs.\n\nOptimizing\n\nI will mainly try to find ways in which I can make the code run better\nor in a nicer way.\n\nDocumenting\n\nSince C is notorious for being a bit “cryptic”, the documentation can\nreally help the newcomers to ease into diving the codebase.\n\nGoals\n\nIncremental rewrite of `git-bisect.sh`\n\nGet all the code written merged.\n\nSome important points\n\nMy semester starts from 18th July so I will start working early just\nto get reviews of the patches thoroughly and\ncode/test/optimize/document properly just to avoid end time hustle and\nso that I can have some buffer time. Also, it would save me from the\nextra burden once my academic session starts. If time permits then I\nwill work on Stephan Beyer’s patches which are related to bisect\nalgorithm and seem quite interesting to me.\n\nTimeline (Tentative)\n\n1st April - 22nd April\n\nSpend time going to the codebase and get familiar with using gdb with\nit. I will mostly concentrate on reading up bisect related areas as\nmentioned above.\n\n2nd May - 8th May (1st week)\n\nStart discussion about the design of bisect and note down the points\nwhich some developers want to be changed. Also see the test suite as\nto what is the expected behavior of a particular bisect related\ncommand.\n\n9th May - 26th June (2nd-8th week)\n\nI count 23 functions (-1 probably) currently in git-bisect.sh . Each\nfunction should take on an average 2 days including code/test/review\nand some functions are quite small. Also by this time I will be quite\nfamiliar with the codebase, review process and conventions so I won’t\nmake many mistakes and the reviews can go faster. Still I have kept\nsome buffer time for just in case some bug comes (which is quite a\nreasonable possibility).\n\n\n27th June - 3rd July (9th week)\n\nTesting - I will mostly test the parts of code that I have written.\nAlso I will explore more on the use of git bisect and try to improve\nits coverage.\n\n\n4th July - 18th July (10th - 11th week)\n\nBug fixing - I will try and fix up some leftover bugs which were\neither introduced because of the conversion or which were already\npresent.\n\n18th July - 24th July (12th week)\n\nOptimizing the C code I have written. Document the code enough so that\nit is easier for a newcomer to dive in.\n\n25th July - 23rd August (left over time)\n\nI will keep this as a buffer period if anything goes wrong with this\ntimeline. Also I wish to work on Stephan Beyer’s patches concerning\nbisect which currently contain 1 leftover bug.\n\n\nMicro-project attempted\n\nI attempted a micro project which will add configurations for commonly\nused command-line options (git commit -v). The link for the patch is\nhere. This is in its last stages and is soon expected to be complete.\n\nDemo function conversion\n\nAs suggested by Johannes Schindelein <Johannes.Schindelein@gmx.de>, I\nhave tried converting one function from shell to C, the function being\ncheck_term_format() to have a taste of how to go about with this\nproject. Here is a link to the patch. This patch is in its final\nstage. This exercise was quite helpful!\n\nPlans for Summer\n\nI currently don’t have any plans for this summer. Though my new\nsemester starts from 18th July. So I will start early.\n\nPossible Mentors\n\nChristian Couder <christian.couder@gmail.com>\n\nMatthieu Moy <Matthieu.Moy@grenoble-inp.fr>\n"},{"id":"281786","messageId":"CAP8UFD0muBUEp9XknmcTWqg==ChzWP3m-p-v6vXyC09OC88U7w@mail.gmail.com","threadId":"41802","inReplyTo":"CAFZEwPNXKo5YN9OPPCkO90bSPD3ittU+y8eDxh-JLxnihBznuw@mail.gmail.com","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-03-25T09:02:20Z","receivedAt":"2016-03-25T09:02:20Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Mar 24, 2016 at 12:27 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:\n> Hey!\n>\n> I have prepared a proposal for Google Summer of Code 2016. I know this\n> is a bit late, but please try to give your comments and suggestions.\n> My proposal could greatly improve from this. Some questions:\n>\n> 1. Should I include more ways in which it can help windows?\n\nI don't think it is necessary.\n\n> 2. Should I include the function names I intend to convert?\n\nI don't think it is necessary, but if you want, you can take a look at\nsome big ones (or perhaps just one big) and explain how you plan to\nconvert it (using which C functions or apis).\n\n> 3. Is my timeline (a bit different) going to affect me in any way?\n\nWhat is important with the timeline is just that it looks realistic.\nSo each task should have a realistic amount of time and the order in\nwhich tasks are listed should be logical.\nI commented below about how I think you could improve your timeline.\n\n> Here is a Google doc for my proposal.\n> https://docs.google.com/document/d/1stnDPA5Hs3u0a8sqoWZicTFpCz1wHP9bkifcKY13Ocw/edit?usp=sharing\n>\n> For the people who prefer the text only version :\n>\n> -----------------------------------------------------------------------------------\n>\n> Incremental rewrite of Git bisect\n>\n> About Me\n>\n> Basic Information\n>\n>\n> Name           Pranit Bauva\n>\n> University     IIT Kharagpur\n>\n> Major            Mining Engineering\n>\n> Email            pranit.bauva@gmail.com\n>\n> IRC              pungi-man\n>\n> Blog             http://bauva.in\n>\n> Timezone     IST (UTC +5:30)\n>\n> Background\n>\n> I am a first year undergraduate in the department of Mining\n> Engineering at Indian Institute of Technology, Kharagpur. I am an open\n> source enthusiast. I am a part of Kharagpur Linux Users Group which is\n> basically a group of open-source enthusiasts. I am quite familiar with\n> C and I have been using shell for some time now and still find new\n> things about it everyday. I have used SVN when I was on Windows and\n> then I switched to Git when I moved to linux. Git seems like magic. I\n> always wanted to involve in the development process and Google Summer\n> of Code is an a awesome way to achieve it.\n>\n>\n> Abstract\n>\n> Git bisect is a frequently used command which helps the developers in\n> finding the commit which introduced the bug. Some part of it is\n> written in shell script. I intend to convert it to low level C code\n> thus making them builtins. This will increase Git’s portability.\n> Efficiency of git bisect will definitely increase but it would not\n> really matter much as most of the time is consumed in compiling or\n> testing when in bisection mode but it will definitely reduce the\n> overhead IO which can make the heavy process of compiling relatively\n> lighter.\n>\n>\n> Problems Shell creates\n>\n> System Dependencies\n>\n> Using shell code introduces various dependencies even though they\n> allowing prototyping of the code quickly. Shell script often use some\n> POSIX utilities like cat, grep, ls, mkdir, etc which are not included\n> in non-POSIX systems by default. These scripts do not have access to\n> the git’s internal low level API. So even trivial tasks have to be\n> performed by spawning new process every time. So when git is ported to\n> windows, it has to include all the utilities (namely a shell\n> interpreter, perl bindings and much more).\n>\n> Scripts introduce extra overheads\n>\n> Shell scripts do not have access to Git’s internal API which has\n> excellent use of cache thus reducing the unnecessary IO of user\n> configuration files, repository index and filesystem access. By using\n> a builtin we could exploit the cache system thus reducing the\n> overhead. As compiling / testing already involves quite a number of\n> resources, it would be good if we could do our best to make more\n> resources available for that.\n>\n> Potential Problems\n>\n> Rewriting may introduce bugs\n>\n> Rewriting the shell script to C might introduce some bugs. This\n> problem will be properly taken care of in my method of approach\n> (described below). Still this approach will definitely not guarantee\n> that the functionality of the new will be exactly similar to the old\n> one, though it will greatly reduce its possibility. The reviews\n> provided by the seniors in the git community would help a lot in\n> reducing bugs since they know the common bugs and how to work around\n> them. The test suite of git is quite nice which has an awesome\n> coverage.\n>\n> Rewritten can be hard to understand\n>\n> Git does not like having many external dependencies, libraries or\n> executables other than what is provided by git itself and the\n> rewritten code should follow this. C does not provide with a lot of\n> other facilities like text processing which shell does whose C\n> implementation often spans to multiple lines. C is also notorious for\n> being a bit “cryptic”. This problem can be compensated by having well\n> written documentation with well defined inputs, outputs and behavior.\n>\n> A peek into git bisect\n>\n> How does it help?\n>\n> Git bisect helps the software developers to find the commit that\n> introduced a regression. Software developers are interested in knowing\n> this because a commit changes a small set of code (most time).  It is\n> much easier to understand and fix a problem when you know only need to\n> check a very small set of changes, than when you don’t know where to\n> look at it. It is not that the problem will be exactly in that commit\n> but it will be related to the behavior introduced in the commit.\n> Software bugs can be a nightmare when the code base is very large.\n> There would be a lot of sleepless night in figuring out the part which\n> causes the error. This is where git bisect helps. This is the one of\n> the most sought after tool in software development.\n>\n> Git bisect algorithm (short description)\n>\n> Git’s commits form a directed acyclic graph (DAG) which makes it a bit\n> difficult to find the bisection commit. The algorithm it uses is :\n>\n> Step 1: Keeps only the ancestors of “bad” commit (including “bad” one)\n> and the commits that are not the ancestors of “good” commit (excluding\n> “good” one). This helps in reducing a lot of “interesting” commits.\n>\n> Step 2: Starting from the good ends (or end), associate some kind of\n> “weight” which depends on its distance from the good commit also\n> considering some other factors.\n>\n> Step 3: Find the midpoint of the max weight which will be the bisection commit.\n>\n> Step 4: Repeat Step 1 but now with one more “good” commit which will\n> cause rearranging of “weights” thus finishing the algorithm which uses\n> binary search.\n>\n> Further details about the algorithm can be found in this article\n> written by Christian Couder.\n\nThe link cannot be seen in text mode but it looks ok on the pdf proposal.\n\n> Current status of git bisect\n>\n> The bisect code is currently spread across multiple files namely\n> git-bisect.sh, bisect.c, bisect.h, and bisect--helper.c . The\n> algorithmic part is written in bisect.c . git-bisect.sh acts like a\n> glue connecting parts of bisect.c with git-rev-list (which helps in\n> listing the commits in various types and formats), git-rev-parse\n> (which helps in knowing the SHA-1 checksum for the ref passed),\n> git-symbolic-refs (to read, modify and delete symbolic refs),\n> git-show-branch (which helps by showing the branches and their\n> respective commits), git-update-ref (to safely update the SHA-1\n> checksum stored in a ref safely), git-for-each-ref (to get information\n> on each ref with given pattern, format, keys and much more) and\n> git-check-ref-format (to check whether the ref has a proper format and\n> doesn’t contain some “special” characters which aren’t allowed) though\n> this is soon going to be replaced by using a sub command\n> `--check-term-format` of bisect--helper whose patch is in its final\n> stages.\n\nThe above sentence is not very clear.\nAnd if you want to talk about all the git features used by\ngit-bisect.sh, you should perhaps separate the bisect related ones\nfrom the other ones, and talk a bit more about the bisect related\nones. For example it looks like you are not talking much about\nbisect--helper.c.\n\n> git-bisect.sh is responsible for writing the respective data\n> concerning the status on bisect to the various files namely\n> BISECT_LOG, BISECT_NAMES, BISECT_START, BISECT_ANCESTORS_OK,\n> BISECT_LOG, refs/bisect and those which would be included in the\n> directory once bisection moves further.\n>\n> How will I go about with this project?\n>\n> Understand related areas\n>\n> In the start, I will focus on understanding the things that\n> git-bisect.sh depends on. I will try to debug that part of code and\n> understand it through documentation. I will also learn to use some\n> more parts of API which I am currently unfamiliar with concerning this\n> project. I will also gain more familiarity with running gdb sessions\n> for big projects.\n>\n> Discussion about the future look of bisect\n>\n> When converting from shell to C, there needs to be quite some amount\n> of changes rather than just plainly translating the code. This is the\n> part where I will discuss with the git community as to what parts they\n> wish they could change it or which are better changed in C. Since C\n> and shell are quite different, approaches which seem good in shell are\n> not that good in C and vice versa. So having a thorough discussion can\n> really help.\n>\n> Convert each function individually\n>\n> Then I will convert each function from shell script to a C builtin in\n> bisect--helper.c individually. This raises a very valid questions as\n> to how to test whether the function performs the tasks as intended\n> since tests suites are written for git-bisect.sh and not\n> bisect--helper.c . To take care for this problem, I will first convert\n> each function to its C builtin and then provide utility in\n> bisect--helper.c so that git-bisect.sh can easily communicate with it.\n> In this way, I can make sure that git-bisect.sh uses a corresponding C\n> builtin rather than origin shell function to run the tests which will\n> help in recognising for any errors (if any) which the patch can have.\n> To help git-bisect.sh communicate, I will make the functions as sub\n> commands in bisect--helper.c so I can ensure that bisect--helper can\n> react in a way which is independant of other sub commands.\n\nThis is a bit verbose. Can't you just say that:\n\n- you will add an option to \"git bisect--helper\" to perform what the\ngit-bisect.sh function did, and\n- you will create a test script for \"git bisect--helper\" in which you\nwill test each option?\n\n> Unification of bisect.c and bisect--helper.c\n>\n> This will unify the algorithmic and non-algorithmic parts of bisect\n> bringing them under one heading to make the code clean.\n\nI am not sure this is needed and a good idea. Maybe you will rename\n\"builtin/bisect--helper.c\" to \"builtin/bisect.c\" and remove\ngit-bisect.sh at the same time to complete the shell to C move. But\nthe actual bisect.{c,h} might be useful as they are for other\npurposes.\n\n> Thorough testing of bisect\n>\n> This will be dedicated for thorough deep testing for any problems\n> which crept in after the shell to C conversion. I will also aim to\n> include some more tests to improve coverage of bisect. If time\n> persists, I will dig further in examining the failing tests and try\n> and fix the bugs.\n\nRight now there are no failing tests and we expect that all the tests\nthat currently succeed will still succeed after the shell to C\nconversion.\nWe want step by step changes so that it is possible to check at each\nstep that no tests fail.\nIf you improve test coverage and see some bugs, then you are indeed\nwelcome to fix those bugs if you have time.\n\n> Optimizing\n>\n> I will mainly try to find ways in which I can make the code run better\n> or in a nicer way.\n>\n> Documenting\n>\n> Since C is notorious for being a bit “cryptic”, the documentation can\n> really help the newcomers to ease into diving the codebase.\n>\n> Goals\n>\n> Incremental rewrite of `git-bisect.sh`\n>\n> Get all the code written merged.\n\nYeah sure, and also it is very important to get code merged early and\noften. It ensures that you are on the right path at each step.\n\nWhen you have sent one patch series, even a small one, then your main\ngoal should be to have this patch series merged.\nIf you can also work on the next patch series that's nice, but you\nshould focus on getting what you have already sent merged first.\n\n> Some important points\n>\n> My semester starts from 18th July so I will start working early just\n> to get reviews of the patches thoroughly and\n> code/test/optimize/document properly just to avoid end time hustle and\n> so that I can have some buffer time.\n\nNice.\n\n> Also, it would save me from the\n> extra burden once my academic session starts. If time permits then I\n> will work on Stephan Beyer’s patches which are related to bisect\n> algorithm and seem quite interesting to me.\n>\n> Timeline (Tentative)\n>\n> 1st April - 22nd April\n>\n> Spend time going to the codebase and get familiar with using gdb with\n> it. I will mostly concentrate on reading up bisect related areas as\n> mentioned above.\n\nAlso please work on getting the current work you already started merged.\n\n> 2nd May - 8th May (1st week)\n>\n> Start discussion about the design of bisect and note down the points\n> which some developers want to be changed. Also see the test suite as\n> to what is the expected behavior of a particular bisect related\n> command.\n\nI don't think the conversion is about changing some behavior. If it\ndoesn't change any behavior at all, which means not introduce any new\nbug, then that would be already very good.\n\n> 9th May - 26th June (2nd-8th week)\n>\n> I count 23 functions (-1 probably) currently in git-bisect.sh . Each\n> function should take on an average 2 days including code/test/review\n> and some functions are quite small. Also by this time I will be quite\n> familiar with the codebase, review process and conventions so I won’t\n> make many mistakes and the reviews can go faster. Still I have kept\n> some buffer time for just in case some bug comes (which is quite a\n> reasonable possibility).\n\nDon't count too much on not making many mistakes, we all make mistakes\nand need many review rounds even after working on Git for many years.\nReviews, responding to reviews, splitting commits, rebasing, testing\nand debugging takes time.\n\n> 27th June - 3rd July (9th week)\n>\n> Testing - I will mostly test the parts of code that I have written.\n\nThat should be done before sending the patchs to the list.\n\n> Also I will explore more on the use of git bisect and try to improve\n> its coverage.\n>\n>\n> 4th July - 18th July (10th - 11th week)\n>\n> Bug fixing - I will try and fix up some leftover bugs which were\n> either introduced because of the conversion or which were already\n> present.\n\nFixing the bugs introduced by the conversion should be done as soon as\nyou know about them.\nSo before sending the patchs to the list, if the bug is found by\nrunning the tests.\n\n> 18th July - 24th July (12th week)\n>\n> Optimizing the C code I have written. Document the code enough so that\n> it is easier for a newcomer to dive in.\n\nDocumentation changes should be sent along with the corresponding code\npatches if possible.\n\n> 25th July - 23rd August (left over time)\n>\n> I will keep this as a buffer period if anything goes wrong with this\n> timeline. Also I wish to work on Stephan Beyer’s patches concerning\n> bisect which currently contain 1 leftover bug.\n>\n>\n> Micro-project attempted\n>\n> I attempted a micro project which will add configurations for commonly\n> used command-line options (git commit -v). The link for the patch is\n> here. This is in its last stages and is soon expected to be complete.\n>\n> Demo function conversion\n>\n> As suggested by Johannes Schindelein <Johannes.Schindelein@gmx.de>, I\n> have tried converting one function from shell to C, the function being\n> check_term_format() to have a taste of how to go about with this\n> project. Here is a link to the patch. This patch is in its final\n> stage. This exercise was quite helpful!\n\nNice.\n\n> Plans for Summer\n>\n> I currently don’t have any plans for this summer. Though my new\n> semester starts from 18th July. So I will start early.\n\nIf you have exams planned from now until the end of August, it would\nbe nice if you could also talk about them.\n\nThanks,\nChristian.\n"},{"id":"281788","messageId":"vpqbn62vrza.fsf@anie.imag.fr","threadId":"41802","inReplyTo":"CAP8UFD0muBUEp9XknmcTWqg==ChzWP3m-p-v6vXyC09OC88U7w@mail.gmail.com","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-03-25T09:15:05Z","receivedAt":"2016-03-25T09:15:05Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> On Thu, Mar 24, 2016 at 12:27 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:\n>\n>> Unification of bisect.c and bisect--helper.c\n>>\n>> This will unify the algorithmic and non-algorithmic parts of bisect\n>> bringing them under one heading to make the code clean.\n>\n> I am not sure this is needed and a good idea. Maybe you will rename\n> \"builtin/bisect--helper.c\" to \"builtin/bisect.c\" and remove\n> git-bisect.sh at the same time to complete the shell to C move. But\n> the actual bisect.{c,h} might be useful as they are for other\n> purposes.\n\nYes. My view on this is that builtin/*.c should be just user-interface,\nand actual stuff should be outside builtin, ideally in a well-designed\nand reusable library (typically re-usable by libgit2 or others to\nprovide another UI for the same feature). Not all commands work this\nway, but I think this is a good direction to take.\n\n> When you have sent one patch series, even a small one, then your main\n> goal should be to have this patch series merged.\n\nI'd add: to get a patch series merged, two things take time:\n\n1) latency: let time to other people to read and comment on your code.\n\n2) extra-work required by reviewers.\n\nYou want to send series early because of 1) (then you can work on the\nnext series while waiting for reviews on the current one), and you need\nto prioritize 2) over working on the next series to minimize in-flight\ntopics.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"281791","messageId":"CAFZEwPMpbpFp7ws6BNzrB-9J7J+JkFLLZwS5JqEY_OgQt2SA+A@mail.gmail.com","threadId":"41802","inReplyTo":"CAP8UFD0muBUEp9XknmcTWqg==ChzWP3m-p-v6vXyC09OC88U7w@mail.gmail.com","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-25T09:50:39Z","receivedAt":"2016-03-25T09:50:39Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Fri, Mar 25, 2016 at 2:32 PM, Christian Couder\n<christian.couder@gmail.com> wrote:\n> On Thu, Mar 24, 2016 at 12:27 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:\n>> Hey!\n>>\n>> I have prepared a proposal for Google Summer of Code 2016. I know this\n>> is a bit late, but please try to give your comments and suggestions.\n>> My proposal could greatly improve from this. Some questions:\n>>\n>> 1. Should I include more ways in which it can help windows?\n>\n> I don't think it is necessary.\n>\n>> 2. Should I include the function names I intend to convert?\n>\n> I don't think it is necessary, but if you want, you can take a look at\n> some big ones (or perhaps just one big) and explain how you plan to\n> convert it (using which C functions or apis).\n\nI try to do it for one big one if there is some time left.\n\n>> 3. Is my timeline (a bit different) going to affect me in any way?\n>\n> What is important with the timeline is just that it looks realistic.\n> So each task should have a realistic amount of time and the order in\n> which tasks are listed should be logical.\n> I commented below about how I think you could improve your timeline.\n\nYour suggestions seem nice to me. I have thought about changing some\nparts. I have described some changes below.\n\n>> Here is a Google doc for my proposal.\n>> https://docs.google.com/document/d/1stnDPA5Hs3u0a8sqoWZicTFpCz1wHP9bkifcKY13Ocw/edit?usp=sharing\n>>\n>> For the people who prefer the text only version :\n>>\n>> -----------------------------------------------------------------------------------\n>>\n>> Incremental rewrite of Git bisect\n>>\n>> About Me\n>>\n>> Basic Information\n>>\n>>\n>> Name           Pranit Bauva\n>>\n>> University     IIT Kharagpur\n>>\n>> Major            Mining Engineering\n>>\n>> Email            pranit.bauva@gmail.com\n>>\n>> IRC              pungi-man\n>>\n>> Blog             http://bauva.in\n>>\n>> Timezone     IST (UTC +5:30)\n>>\n>> Background\n>>\n>> I am a first year undergraduate in the department of Mining\n>> Engineering at Indian Institute of Technology, Kharagpur. I am an open\n>> source enthusiast. I am a part of Kharagpur Linux Users Group which is\n>> basically a group of open-source enthusiasts. I am quite familiar with\n>> C and I have been using shell for some time now and still find new\n>> things about it everyday. I have used SVN when I was on Windows and\n>> then I switched to Git when I moved to linux. Git seems like magic. I\n>> always wanted to involve in the development process and Google Summer\n>> of Code is an a awesome way to achieve it.\n>>\n>>\n>> Abstract\n>>\n>> Git bisect is a frequently used command which helps the developers in\n>> finding the commit which introduced the bug. Some part of it is\n>> written in shell script. I intend to convert it to low level C code\n>> thus making them builtins. This will increase Git’s portability.\n>> Efficiency of git bisect will definitely increase but it would not\n>> really matter much as most of the time is consumed in compiling or\n>> testing when in bisection mode but it will definitely reduce the\n>> overhead IO which can make the heavy process of compiling relatively\n>> lighter.\n>>\n>>\n>> Problems Shell creates\n>>\n>> System Dependencies\n>>\n>> Using shell code introduces various dependencies even though they\n>> allowing prototyping of the code quickly. Shell script often use some\n>> POSIX utilities like cat, grep, ls, mkdir, etc which are not included\n>> in non-POSIX systems by default. These scripts do not have access to\n>> the git’s internal low level API. So even trivial tasks have to be\n>> performed by spawning new process every time. So when git is ported to\n>> windows, it has to include all the utilities (namely a shell\n>> interpreter, perl bindings and much more).\n>>\n>> Scripts introduce extra overheads\n>>\n>> Shell scripts do not have access to Git’s internal API which has\n>> excellent use of cache thus reducing the unnecessary IO of user\n>> configuration files, repository index and filesystem access. By using\n>> a builtin we could exploit the cache system thus reducing the\n>> overhead. As compiling / testing already involves quite a number of\n>> resources, it would be good if we could do our best to make more\n>> resources available for that.\n>>\n>> Potential Problems\n>>\n>> Rewriting may introduce bugs\n>>\n>> Rewriting the shell script to C might introduce some bugs. This\n>> problem will be properly taken care of in my method of approach\n>> (described below). Still this approach will definitely not guarantee\n>> that the functionality of the new will be exactly similar to the old\n>> one, though it will greatly reduce its possibility. The reviews\n>> provided by the seniors in the git community would help a lot in\n>> reducing bugs since they know the common bugs and how to work around\n>> them. The test suite of git is quite nice which has an awesome\n>> coverage.\n>>\n>> Rewritten can be hard to understand\n>>\n>> Git does not like having many external dependencies, libraries or\n>> executables other than what is provided by git itself and the\n>> rewritten code should follow this. C does not provide with a lot of\n>> other facilities like text processing which shell does whose C\n>> implementation often spans to multiple lines. C is also notorious for\n>> being a bit “cryptic”. This problem can be compensated by having well\n>> written documentation with well defined inputs, outputs and behavior.\n>>\n>> A peek into git bisect\n>>\n>> How does it help?\n>>\n>> Git bisect helps the software developers to find the commit that\n>> introduced a regression. Software developers are interested in knowing\n>> this because a commit changes a small set of code (most time).  It is\n>> much easier to understand and fix a problem when you know only need to\n>> check a very small set of changes, than when you don’t know where to\n>> look at it. It is not that the problem will be exactly in that commit\n>> but it will be related to the behavior introduced in the commit.\n>> Software bugs can be a nightmare when the code base is very large.\n>> There would be a lot of sleepless night in figuring out the part which\n>> causes the error. This is where git bisect helps. This is the one of\n>> the most sought after tool in software development.\n>>\n>> Git bisect algorithm (short description)\n>>\n>> Git’s commits form a directed acyclic graph (DAG) which makes it a bit\n>> difficult to find the bisection commit. The algorithm it uses is :\n>>\n>> Step 1: Keeps only the ancestors of “bad” commit (including “bad” one)\n>> and the commits that are not the ancestors of “good” commit (excluding\n>> “good” one). This helps in reducing a lot of “interesting” commits.\n>>\n>> Step 2: Starting from the good ends (or end), associate some kind of\n>> “weight” which depends on its distance from the good commit also\n>> considering some other factors.\n>>\n>> Step 3: Find the midpoint of the max weight which will be the bisection commit.\n>>\n>> Step 4: Repeat Step 1 but now with one more “good” commit which will\n>> cause rearranging of “weights” thus finishing the algorithm which uses\n>> binary search.\n>>\n>> Further details about the algorithm can be found in this article\n>> written by Christian Couder.\n>\n> The link cannot be seen in text mode but it looks ok on the pdf proposal.\n\nI forgot to link it in the text only version.\n\n>\n>> Current status of git bisect\n>>\n>> The bisect code is currently spread across multiple files namely\n>> git-bisect.sh, bisect.c, bisect.h, and bisect--helper.c . The\n>> algorithmic part is written in bisect.c . git-bisect.sh acts like a\n>> glue connecting parts of bisect.c with git-rev-list (which helps in\n>> listing the commits in various types and formats), git-rev-parse\n>> (which helps in knowing the SHA-1 checksum for the ref passed),\n>> git-symbolic-refs (to read, modify and delete symbolic refs),\n>> git-show-branch (which helps by showing the branches and their\n>> respective commits), git-update-ref (to safely update the SHA-1\n>> checksum stored in a ref safely), git-for-each-ref (to get information\n>> on each ref with given pattern, format, keys and much more) and\n>> git-check-ref-format (to check whether the ref has a proper format and\n>> doesn’t contain some “special” characters which aren’t allowed) though\n>> this is soon going to be replaced by using a sub command\n>> `--check-term-format` of bisect--helper whose patch is in its final\n>> stages.\n>\n> The above sentence is not very clear.\n> And if you want to talk about all the git features used by\n> git-bisect.sh, you should perhaps separate the bisect related ones\n> from the other ones, and talk a bit more about the bisect related\n> ones. For example it looks like you are not talking much about\n> bisect--helper.c.\n\nI will include the talk about bisect--helper.c\n\n>> git-bisect.sh is responsible for writing the respective data\n>> concerning the status on bisect to the various files namely\n>> BISECT_LOG, BISECT_NAMES, BISECT_START, BISECT_ANCESTORS_OK,\n>> BISECT_LOG, refs/bisect and those which would be included in the\n>> directory once bisection moves further.\n>>\n>> How will I go about with this project?\n>>\n>> Understand related areas\n>>\n>> In the start, I will focus on understanding the things that\n>> git-bisect.sh depends on. I will try to debug that part of code and\n>> understand it through documentation. I will also learn to use some\n>> more parts of API which I am currently unfamiliar with concerning this\n>> project. I will also gain more familiarity with running gdb sessions\n>> for big projects.\n>>\n>> Discussion about the future look of bisect\n>>\n>> When converting from shell to C, there needs to be quite some amount\n>> of changes rather than just plainly translating the code. This is the\n>> part where I will discuss with the git community as to what parts they\n>> wish they could change it or which are better changed in C. Since C\n>> and shell are quite different, approaches which seem good in shell are\n>> not that good in C and vice versa. So having a thorough discussion can\n>> really help.\n>>\n>> Convert each function individually\n>>\n>> Then I will convert each function from shell script to a C builtin in\n>> bisect--helper.c individually. This raises a very valid questions as\n>> to how to test whether the function performs the tasks as intended\n>> since tests suites are written for git-bisect.sh and not\n>> bisect--helper.c . To take care for this problem, I will first convert\n>> each function to its C builtin and then provide utility in\n>> bisect--helper.c so that git-bisect.sh can easily communicate with it.\n>> In this way, I can make sure that git-bisect.sh uses a corresponding C\n>> builtin rather than origin shell function to run the tests which will\n>> help in recognising for any errors (if any) which the patch can have.\n>> To help git-bisect.sh communicate, I will make the functions as sub\n>> commands in bisect--helper.c so I can ensure that bisect--helper can\n>> react in a way which is independant of other sub commands.\n>\n> This is a bit verbose. Can't you just say that:\n>\n> - you will add an option to \"git bisect--helper\" to perform what the\n> git-bisect.sh function did, and\n> - you will create a test script for \"git bisect--helper\" in which you\n> will test each option?\n\nThis looks clearer and describes nicely.\n\n>> Unification of bisect.c and bisect--helper.c\n>>\n>> This will unify the algorithmic and non-algorithmic parts of bisect\n>> bringing them under one heading to make the code clean.\n>\n> I am not sure this is needed and a good idea. Maybe you will rename\n> \"builtin/bisect--helper.c\" to \"builtin/bisect.c\" and remove\n> git-bisect.sh at the same time to complete the shell to C move. But\n> the actual bisect.{c,h} might be useful as they are for other\n> purposes.\n\nOkay. I will drop this off.\n\n>> Thorough testing of bisect\n>>\n>> This will be dedicated for thorough deep testing for any problems\n>> which crept in after the shell to C conversion. I will also aim to\n>> include some more tests to improve coverage of bisect. If time\n>> persists, I will dig further in examining the failing tests and try\n>> and fix the bugs.\n>\n> Right now there are no failing tests and we expect that all the tests\n> that currently succeed will still succeed after the shell to C\n> conversion.\n> We want step by step changes so that it is possible to check at each\n> step that no tests fail.\n> If you improve test coverage and see some bugs, then you are indeed\n> welcome to fix those bugs if you have time.\n\nWhat I meant to do was that there are some tests which are marked\n\"TODO breakdown\" and I will try and fix those. I understand that its\nnot clear and I will modify this in the proposal.\n\n>\n>> Optimizing\n>>\n>> I will mainly try to find ways in which I can make the code run better\n>> or in a nicer way.\n>>\n>> Documenting\n>>\n>> Since C is notorious for being a bit “cryptic”, the documentation can\n>> really help the newcomers to ease into diving the codebase.\n>>\n>> Goals\n>>\n>> Incremental rewrite of `git-bisect.sh`\n>>\n>> Get all the code written merged.\n>\n> Yeah sure, and also it is very important to get code merged early and\n> often. It ensures that you are on the right path at each step.\n>\n> When you have sent one patch series, even a small one, then your main\n> goal should be to have this patch series merged.\n> If you can also work on the next patch series that's nice, but you\n> should focus on getting what you have already sent merged first.\n\nSure. I was thinking about doing some parallel work as there is some\ntime gap involved in between reviews. But this also creates some\nconfusion for me and I tend to forget some things which I were\ndiscussed and I had thought about. But I can maintain a notebook (hard\ncopy) to jot down all the stuff so that I don't forget.\n\n>> Some important points\n>>\n>> My semester starts from 18th July so I will start working early just\n>> to get reviews of the patches thoroughly and\n>> code/test/optimize/document properly just to avoid end time hustle and\n>> so that I can have some buffer time.\n>\n> Nice.\n>\n>> Also, it would save me from the\n>> extra burden once my academic session starts. If time permits then I\n>> will work on Stephan Beyer’s patches which are related to bisect\n>> algorithm and seem quite interesting to me.\n>>\n>> Timeline (Tentative)\n>>\n>> 1st April - 22nd April\n>>\n>> Spend time going to the codebase and get familiar with using gdb with\n>> it. I will mostly concentrate on reading up bisect related areas as\n>> mentioned above.\n>\n> Also please work on getting the current work you already started merged.\n>\n>> 2nd May - 8th May (1st week)\n>>\n>> Start discussion about the design of bisect and note down the points\n>> which some developers want to be changed. Also see the test suite as\n>> to what is the expected behavior of a particular bisect related\n>> command.\n>\n> I don't think the conversion is about changing some behavior. If it\n> doesn't change any behavior at all, which means not introduce any new\n> bug, then that would be already very good.\n\nSure. What I was thinking that there might be some things which were\neither too small to do or too big to do which could be done during\nthis conversion. But if you say there aren't any then it is best not\nto change anything.\n\n>> 9th May - 26th June (2nd-8th week)\n>>\n>> I count 23 functions (-1 probably) currently in git-bisect.sh . Each\n>> function should take on an average 2 days including code/test/review\n>> and some functions are quite small. Also by this time I will be quite\n>> familiar with the codebase, review process and conventions so I won’t\n>> make many mistakes and the reviews can go faster. Still I have kept\n>> some buffer time for just in case some bug comes (which is quite a\n>> reasonable possibility).\n>\n> Don't count too much on not making many mistakes, we all make mistakes\n> and need many review rounds even after working on Git for many years.\n> Reviews, responding to reviews, splitting commits, rebasing, testing\n> and debugging takes time.\n\nNow that I think about this, I should give this even more time.\n\n>> 27th June - 3rd July (9th week)\n>>\n>> Testing - I will mostly test the parts of code that I have written.\n>\n> That should be done before sending the patchs to the list.\n\nI will squash this with conversion period.\n\n>\n>> Also I will explore more on the use of git bisect and try to improve\n>> its coverage.\n>>\n>>\n>> 4th July - 18th July (10th - 11th week)\n>>\n>> Bug fixing - I will try and fix up some leftover bugs which were\n>> either introduced because of the conversion or which were already\n>> present.\n>\n> Fixing the bugs introduced by the conversion should be done as soon as\n> you know about them.\n> So before sending the patchs to the list, if the bug is found by\n> running the tests.\n\nI meant to keep this week as let's say in between there is some bug\nwhich I am not able to fix at all. So I will mark it as TODO, if it\nwill not affect any future patches, for after wards and then will try\nto fix it. Is it something not recommended ?\n\n>> 18th July - 24th July (12th week)\n>>\n>> Optimizing the C code I have written. Document the code enough so that\n>> it is easier for a newcomer to dive in.\n>\n> Documentation changes should be sent along with the corresponding code\n> patches if possible.\n\nI will squash this week into the conversion period only.\n\n>> 25th July - 23rd August (left over time)\n>>\n>> I will keep this as a buffer period if anything goes wrong with this\n>> timeline. Also I wish to work on Stephan Beyer’s patches concerning\n>> bisect which currently contain 1 leftover bug.\n>>\n>>\n>> Micro-project attempted\n>>\n>> I attempted a micro project which will add configurations for commonly\n>> used command-line options (git commit -v). The link for the patch is\n>> here. This is in its last stages and is soon expected to be complete.\n>>\n>> Demo function conversion\n>>\n>> As suggested by Johannes Schindelein <Johannes.Schindelein@gmx.de>, I\n>> have tried converting one function from shell to C, the function being\n>> check_term_format() to have a taste of how to go about with this\n>> project. Here is a link to the patch. This patch is in its final\n>> stage. This exercise was quite helpful!\n>\n> Nice.\n>\n>> Plans for Summer\n>>\n>> I currently don’t have any plans for this summer. Though my new\n>> semester starts from 18th July. So I will start early.\n>\n> If you have exams planned from now until the end of August, it would\n> be nice if you could also talk about them.\n\nI should mention this clearly in the proposal. I have my spring\nsemester exams from 22nd April to 29th April. I don't have any other\ntests/exams in between till August. This semester has been a peaceful\none for me and I have been following the courses properly (except for\nthis micro project period of around 3 weeks). Many seniors have told\nme that the forthcoming autumn semester is quite an intense one. So I\nthink its for the best that I work when I can.\n"},{"id":"281793","messageId":"CAFZEwPN7HhjiQ=WdJUvK-4c1XL1X=27m8xF7MZab92v+aK-9ww@mail.gmail.com","threadId":"41802","inReplyTo":"vpqbn62vrza.fsf@anie.imag.fr","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-25T09:58:01Z","receivedAt":"2016-03-25T09:58:01Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Fri, Mar 25, 2016 at 2:45 PM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Christian Couder <christian.couder@gmail.com> writes:\n>\n>> On Thu, Mar 24, 2016 at 12:27 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:\n>>\n>>> Unification of bisect.c and bisect--helper.c\n>>>\n>>> This will unify the algorithmic and non-algorithmic parts of bisect\n>>> bringing them under one heading to make the code clean.\n>>\n>> I am not sure this is needed and a good idea. Maybe you will rename\n>> \"builtin/bisect--helper.c\" to \"builtin/bisect.c\" and remove\n>> git-bisect.sh at the same time to complete the shell to C move. But\n>> the actual bisect.{c,h} might be useful as they are for other\n>> purposes.\n>\n> Yes. My view on this is that builtin/*.c should be just user-interface,\n> and actual stuff should be outside builtin, ideally in a well-designed\n> and reusable library (typically re-usable by libgit2 or others to\n> provide another UI for the same feature). Not all commands work this\n> way, but I think this is a good direction to take.\n\nOkay. I didn't know about this. Thanks for completing Christian's point.\n\n>> When you have sent one patch series, even a small one, then your main\n>> goal should be to have this patch series merged.\n>\n> I'd add: to get a patch series merged, two things take time:\n>\n> 1) latency: let time to other people to read and comment on your code.\n>\n> 2) extra-work required by reviewers.\n>\n> You want to send series early because of 1) (then you can work on the\n> next series while waiting for reviews on the current one), and you need\n> to prioritize 2) over working on the next series to minimize in-flight\n> topics.\n\nI had planned to work this way. I will include this in the proposal.\nThough it creates some confusion for me and I tend to mix some things\nup but I will maintain a hard copy to jot down the discussions and my\nthoughts.\n"},{"id":"281797","messageId":"CAFZEwPM=+U8gC0JRL1Zi6yJboenuSw6hBKJeLNzf_=NYQTCSGA@mail.gmail.com","threadId":"41802","inReplyTo":"CAP8UFD0muBUEp9XknmcTWqg==ChzWP3m-p-v6vXyC09OC88U7w@mail.gmail.com","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-25T10:15:05Z","receivedAt":"2016-03-25T10:15:05Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"> - you will add an option to \"git bisect--helper\" to perform what the\n> git-bisect.sh function did, and\n> - you will create a test script for \"git bisect--helper\" in which you\n> will test each option?\n\nI had very initially planned to do this. But Matthieu pointed out that\nit would be much better to use the existing test suite rather than\ncreating one which can lead to less coverage.\n\nThanks,\nPranit Bauva\n"},{"id":"281802","messageId":"CAP8UFD0vm1Sn07ickfPz5segbM-M7+HR43CMMGsB9WTqj5s-yw@mail.gmail.com","threadId":"41802","inReplyTo":"CAFZEwPM=+U8gC0JRL1Zi6yJboenuSw6hBKJeLNzf_=NYQTCSGA@mail.gmail.com","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-03-25T11:40:58Z","receivedAt":"2016-03-25T11:40:58Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Mar 25, 2016 at 11:15 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:\n>> - you will add an option to \"git bisect--helper\" to perform what the\n>> git-bisect.sh function did, and\n>> - you will create a test script for \"git bisect--helper\" in which you\n>> will test each option?\n>\n> I had very initially planned to do this. But Matthieu pointed out that\n> it would be much better to use the existing test suite rather than\n> creating one which can lead to less coverage.\n\nOk, then perhaps:\n\n- you will add tests to existing test scripts, so that each \"git\nbisect--helper\" option is (indirectly) tested.\n"},{"id":"281804","messageId":"CAFZEwPPKE1kODzSD4ZqZOehSB2SUUAC5JF-j7__kA2obpV92Tw@mail.gmail.com","threadId":"41802","inReplyTo":"CAP8UFD0vm1Sn07ickfPz5segbM-M7+HR43CMMGsB9WTqj5s-yw@mail.gmail.com","subject":"Re: GSoC 2016 | Proposal | Incremental Rewrite of git bisect","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-25T11:43:58Z","receivedAt":"2016-03-25T11:43:58Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Fri, Mar 25, 2016 at 5:10 PM, Christian Couder\n<christian.couder@gmail.com> wrote:\n> On Fri, Mar 25, 2016 at 11:15 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:\n>>> - you will add an option to \"git bisect--helper\" to perform what the\n>>> git-bisect.sh function did, and\n>>> - you will create a test script for \"git bisect--helper\" in which you\n>>> will test each option?\n>>\n>> I had very initially planned to do this. But Matthieu pointed out that\n>> it would be much better to use the existing test suite rather than\n>> creating one which can lead to less coverage.\n>\n> Ok, then perhaps:\n>\n> - you will add tests to existing test scripts, so that each \"git\n> bisect--helper\" option is (indirectly) tested.\nYes. I will mention this in the proposal also. Thanks for reminding.\n"}]}