{"thread":{"id":"36253","subject":"[RFC] [GSoC] Draft of Proposal for GSoC","startedAt":"2014-03-20T18:15:29Z","lastAt":"2014-03-21T18:35:42Z","messageCount":8,"participants":["Brian Bourn","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"237191","messageId":"CAM+=D-BWCt9kNSUUQ19ZcPykb6j-tuEr=igBz0ukEk2TA3vWkg@mail.gmail.com","threadId":"36253","inReplyTo":null,"subject":"[RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Brian Bourn","fromEmail":"ba.bourn@gmail.com","sentAt":"2014-03-20T18:15:29Z","receivedAt":"2014-03-20T18:15:29Z","isPatch":false,"sender":{"key":"ba.bourn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3165958?v=4"},"body":"Hi all,\n\nThis is a first draft of my Proposal for GSoC, I'd love feedback about\nwhat I might be missing and any other files I should read regarding\nthis, so far I have read most of tag.c, branch.c,\nbuiltin/for-each-ref.c, parse-options.c. once again I hope I can get\nthe same amount of helpful feedback as when I submitted my\nMicroproject.\n\nMy name is Brian Bourn, I'm currently a computer engineering student\nat Columbia university in the city of New York.  I've used git since\nmy freshman year however this past week has been my first time\nattempting to contribute to the project, and I loved it. I'd\nparticularly like to tackle Unifying git branch -l, git tag -l, and\ngit for-each-ref.  This functionality seems like an important update\nto me as it will simplify usage of git throughout three different\ncommands, a noble pursuit which is not contained in any other project.\n\nGoing through the annals of the listserve thus far I've found a few\ndiscussions which provide some insight towards this process as well as\nsome experimental patches that never seem to have made it\nthrough[1][2][3][4]\n\nI would start by beginning a deprecation plan for git branch -l very\nsimilar to the one Junio presents in [5], moving -create-reflog to -g,\n\nFollowing this I would begin the real work of the project which would\ninvolve moving the following flag operations into a standard library\nsay 'list-options.h'\n\n--contains [6]\n--merged [7]\n--no-merged[8]\n--format\nThis Library would build these options for later interpretation by parse_options\n\nNext I would implement these flags in the three files so that they are\nuniform and the same formatting and list capabilities can be used on\nall three. The formatting option will be especially useful for branch\nand tag as it will allow users to better understand what is in each\nref that they grab.\n\nFor the most part I haven't finalized my weekly schedule but a basic\nbreakdown would be\n\nStart-Midterm\nBegin deprecation of -l\nSpend some time reading *.c files even deeper\nBuild Library(dedicate Minimum one week per function moved)\n\nMidterm-finish\nImplement the list flags\nImplement the format flags\n(if time is left over, add some formatting)\n\nAdditionally I am thinking about adding some more formatting tools\nsuch as numbering outputs. What do you all think of this?\n\n\n[1]http://git.661346.n2.nabble.com/More-formatting-with-git-tag-l-tt6739049.html\n\n[2]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6725483\n\n[3]http://git.661346.n2.nabble.com/RFC-PATCH-tag-make-list-exclude-lt-pattern-gt-tt7270451.html#a7338712\n\n [4]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6728878\n\n[5]http://git.661346.n2.nabble.com/RFC-PATCH-0-2-RFC-POC-patterns-for-branch-list-tt6309233.html\n\n[6]https://github.com/git/git/blob/master/builtin/branch.c#L817\n\n[7] https://github.com/git/git/blob/master/builtin/branch.c#L849\n\n[8] https://github.com/git/git/blob/master/builtin/branch.c#L843\n\nRegards,\nBrian Bourn\n"},{"id":"237256","messageId":"CAM+=D-D6Vn613YuadqiByhYk9gFM8MLfiS_x=YcYb-9qHQTgOg@mail.gmail.com","threadId":"36253","inReplyTo":"CAM+=D-BWCt9kNSUUQ19ZcPykb6j-tuEr=igBz0ukEk2TA3vWkg@mail.gmail.com","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Brian Bourn","fromEmail":"ba.bourn@gmail.com","sentAt":"2014-03-21T03:39:34Z","receivedAt":"2014-03-21T03:39:34Z","isPatch":false,"sender":{"key":"ba.bourn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3165958?v=4"},"body":"Hello again,\n\nPlease it would be very helpful for me to get some comments on this\nproposal I would be very grateful towards anyone who could take some\ntime to look at it, even if it's just the wording.\nRegards,\nBrian Bourn\n\n\nOn Thu, Mar 20, 2014 at 2:15 PM, Brian Bourn <ba.bourn@gmail.com> wrote:\n> Hi all,\n>\n> This is a first draft of my Proposal for GSoC, I'd love feedback about\n> what I might be missing and any other files I should read regarding\n> this, so far I have read most of tag.c, branch.c,\n> builtin/for-each-ref.c, parse-options.c. once again I hope I can get\n> the same amount of helpful feedback as when I submitted my\n> Microproject.\n>\n> My name is Brian Bourn, I'm currently a computer engineering student\n> at Columbia university in the city of New York.  I've used git since\n> my freshman year however this past week has been my first time\n> attempting to contribute to the project, and I loved it. I'd\n> particularly like to tackle Unifying git branch -l, git tag -l, and\n> git for-each-ref.  This functionality seems like an important update\n> to me as it will simplify usage of git throughout three different\n> commands, a noble pursuit which is not contained in any other project.\n>\n> Going through the annals of the listserve thus far I've found a few\n> discussions which provide some insight towards this process as well as\n> some experimental patches that never seem to have made it\n> through[1][2][3][4]\n>\n> I would start by beginning a deprecation plan for git branch -l very\n> similar to the one Junio presents in [5], moving -create-reflog to -g,\n>\n> Following this I would begin the real work of the project which would\n> involve moving the following flag operations into a standard library\n> say 'list-options.h'\n>\n> --contains [6]\n> --merged [7]\n> --no-merged[8]\n> --format\n> This Library would build these options for later interpretation by parse_options\n>\n> Next I would implement these flags in the three files so that they are\n> uniform and the same formatting and list capabilities can be used on\n> all three. The formatting option will be especially useful for branch\n> and tag as it will allow users to better understand what is in each\n> ref that they grab.\n>\n> For the most part I haven't finalized my weekly schedule but a basic\n> breakdown would be\n>\n> Start-Midterm\n> Begin deprecation of -l\n> Spend some time reading *.c files even deeper\n> Build Library(dedicate Minimum one week per function moved)\n>\n> Midterm-finish\n> Implement the list flags\n> Implement the format flags\n> (if time is left over, add some formatting)\n>\n> Additionally I am thinking about adding some more formatting tools\n> such as numbering outputs. What do you all think of this?\n>\n>\n> [1]http://git.661346.n2.nabble.com/More-formatting-with-git-tag-l-tt6739049.html\n>\n> [2]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6725483\n>\n> [3]http://git.661346.n2.nabble.com/RFC-PATCH-tag-make-list-exclude-lt-pattern-gt-tt7270451.html#a7338712\n>\n>  [4]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6728878\n>\n> [5]http://git.661346.n2.nabble.com/RFC-PATCH-0-2-RFC-POC-patterns-for-branch-list-tt6309233.html\n>\n> [6]https://github.com/git/git/blob/master/builtin/branch.c#L817\n>\n> [7] https://github.com/git/git/blob/master/builtin/branch.c#L849\n>\n> [8] https://github.com/git/git/blob/master/builtin/branch.c#L843\n>\n> Regards,\n> Brian Bourn\n"},{"id":"237265","messageId":"20140321054208.GA31737@sigill.intra.peff.net","threadId":"36253","inReplyTo":"CAM+=D-BWCt9kNSUUQ19ZcPykb6j-tuEr=igBz0ukEk2TA3vWkg@mail.gmail.com","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-21T05:42:08Z","receivedAt":"2014-03-21T05:42:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 20, 2014 at 02:15:29PM -0400, Brian Bourn wrote:\n\n> Going through the annals of the listserve thus far I've found a few\n> discussions which provide some insight towards this process as well as\n> some experimental patches that never seem to have made it\n> through[1][2][3][4]\n\nReading the past work in this area is a good way to get familiar with\nit. It looks like most of the features discussed in the threads you link\nhave been implemented. The one exception seems to be negative patterns.\nI think that would be a good feature to build on top of the unified\nimplementation, once all three commands are using it.\n\n> I would start by beginning a deprecation plan for git branch -l very\n> similar to the one Junio presents in [5], moving -create-reflog to -g,\n\nThat makes sense. I hadn't really considered \"-l\" as another point of\ninconsistency between the commands, but it definitely is.\n\n> Following this I would begin the real work of the project which would\n> involve moving the following flag operations into a standard library\n> say 'list-options.h'\n> \n> --contains [6]\n> --merged [7]\n> --no-merged[8]\n> --format\n> This Library would build these options for later interpretation by parse_options\n\nCan you sketch out what the API would look like for this unified\nlibrary? What calls would the 3 programs need to make into it?\n\n> For the most part I haven't finalized my weekly schedule but a basic\n> breakdown would be\n\nCan you go into more detail here? Remember that writing code is only one\npart of the project. You'll need to be submitting your work, getting\nreview and feedback, and iterating on it.\n\nOne problem that students have is queuing up a large amount of work to\nsend to the list. Then they twiddle their thumbs waiting for review to\ncome back (which takes a long time, because they just dumped a large\nbody of work on the reviewers). If you want to make effective use of\nyour time, it helps to try to break tasks down into smaller chunks, and\nthink about the dependencies between the chunks. When one chunk is in\nreview, you can be designing and coding on another.\n\n> Additionally I am thinking about adding some more formatting tools\n> such as numbering outputs. What do you all think of this?\n\nSomething like numbering might make sense as part of the formatting code\n(e.g., a new placeholder that expands to \"n\" for the nth line of\noutput). I think that would be fairly straightforward, but again, it\nmakes sense to me to unify the implementations first, and then we can\nbuild new features on top.\n\n-Peff\n"},{"id":"237306","messageId":"CAM+=D-ATimdXmcYpqSyKwZXE=TYXg9cZFG9kyjEOg22K1wF+3Q@mail.gmail.com","threadId":"36253","inReplyTo":"20140321054208.GA31737@sigill.intra.peff.net","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Brian Bourn","fromEmail":"ba.bourn@gmail.com","sentAt":"2014-03-21T09:41:36Z","receivedAt":"2014-03-21T09:41:36Z","isPatch":false,"sender":{"key":"ba.bourn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3165958?v=4"},"body":"Parts of v2, once again, i'd love some more comments on what I've\nrewritten\n\n\nOn Fri, Mar 21, 2014 at 1:42 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Mar 20, 2014 at 02:15:29PM -0400, Brian Bourn wrote:\n>\n>> Going through the annals of the listserve thus far I've found a few\n>> discussions which provide some insight towards this process as well as\n>> some experimental patches that never seem to have made it\n>> through[1][2][3][4]\n>\n> Reading the past work in this area is a good way to get familiar with\n> it. It looks like most of the features discussed in the threads you link\n> have been implemented. The one exception seems to be negative patterns.\n> I think that would be a good feature to build on top of the unified\n> implementation, once all three commands are using it.\n>\n>> I would start by beginning a deprecation plan for git branch -l very\n>> similar to the one Junio presents in [5], moving -create-reflog to -g,\n>\n> That makes sense. I hadn't really considered \"-l\" as another point of\n> inconsistency between the commands, but it definitely is.\n>\n>> Following this I would begin the real work of the project which would\n>> involve moving the following flag operations into a standard library\n>> say 'list-options.h'\n>>\n>> --contains [6]\n>> --merged [7]\n>> --no-merged[8]\n>> --format\n>> This Library would build these options for later interpretation by parse_options\n> Can you sketch out what the API would look like for this unified\n> library? What calls would the 3 programs need to make into it?\n>\n\nSomething like this?\n\nSample api calls\nAdd_Opt_Group()\nParse_with_contains()\nParse_with_merged()\nParse_with_no_merged()\nParse_with_formatting()\n(each of the 4 calls above may have internal calls within the library\nin order to parse the option for each of the different function which\nmay call these functions)\n\n\n>> For the most part I haven't finalized my weekly schedule but a basic\n>> breakdown would be\n>\n> Can you go into more detail here? Remember that writing code is only one\n> part of the project. You'll need to be submitting your work, getting\n> review and feedback, and iterating on it.\n>\n> One problem that students have is queuing up a large amount of work to\n> send to the list. Then they twiddle their thumbs waiting for review to\n> come back (which takes a long time, because they just dumped a large\n> body of work on the reviewers). If you want to make effective use of\n> your time, it helps to try to break tasks down into smaller chunks, and\n> think about the dependencies between the chunks. When one chunk is in\n> review, you can be designing and coding on another.\n\nThis one I can absolutely understand, I tried to break this part down into very\nmanagable parts and give myself a little time at the end of each coding period\nto clean up each previous section.  this slop time also allows for me\nto hopefully\nadd some of the extra features that have been thought of. I'm thinking something\nlike this makes it a little better,\n\nWeekly Schedule\n\nStart-Midterm\nWeek 1- Begin deprecation of -l in git branch/establish exactly how\nlong each stage of the deprecation should take.  Spend some time\nreading *.c files even deeper while getting to know any current\npatches occurring in any area near my work files.  Lastly, this week\nwill be spent going through the Mailing-list finding previous work\ndone in this area and any other experimental patches\nWeek 2- Move Opt_Group callbacks for the functions  into Library\nWeek 3-Make a Contains Function in the library which will work for all\nthree functions\nWeek 4-Add Merge function in library\nWeek 5-Add a No Merge function in library\nWeeks 7-8 spend time polishing the library and cleaning up the patches\nfor final submission of library to the project\n\nDeliverables for midterm- Library finished pending polish and\nacceptance into the git repository\n\nMidterm\n\nWeek 9- refactor all files to use the contains flag from the file.\nWeek 10- use Merge from library in all relevant files\nWeek 11-use no-merge from library in all relevant files\nWeek 11-12- implement the format flags in all relevant files (this\nwill be slightly harder as I think this might involve calling\nfor-each-ref in the code for tag and branch. Ultimately there is a\nchance that part of the code for doing for-each-ref will end up in\nthis library as well), additionally add in the code for formatting the\nrelevant opt_Groups into the necessary files.\nWeek 13-14 Polish patches via mailing-list and clean up all the\nrefactoring of the files that has occurred.(optionally, add more\nformatting changes such as negative patterns and numbering each output\ninto the library).\n\nDeliverables for Final- working library hopefully added into the code,\nand all of the relevant patches for using the library mostly polished\nand, minimally, pending peer review for submission into the code base.\n\nI do wonder if this plan might be a little on the conservative side,\nif anything, I think\nthis could take a slightly shorter time than planned, but In that case\nI can always\nwork on other additions to format.\n\n\n>\n>> Additionally I am thinking about adding some more formatting tools\n>> such as numbering outputs. What do you all think of this?\n>\n> Something like numbering might make sense as part of the formatting code\n> (e.g., a new placeholder that expands to \"n\" for the nth line of\n> output). I think that would be fairly straightforward, but again, it\n> makes sense to me to unify the implementations first, and then we can\n> build new features on top.\n>\n> -Peff\n"},{"id":"237331","messageId":"xmqq8us3v42o.fsf@gitster.dls.corp.google.com","threadId":"36253","inReplyTo":"CAM+=D-ATimdXmcYpqSyKwZXE=TYXg9cZFG9kyjEOg22K1wF+3Q@mail.gmail.com","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-21T17:45:03Z","receivedAt":"2014-03-21T17:45:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Bourn <ba.bourn@gmail.com> writes:\n\n> Something like this?\n>\n> Sample api calls\n> Add_Opt_Group()\n> Parse_with_contains()\n> Parse_with_merged()\n> Parse_with_no_merged()\n> Parse_with_formatting()\n> (each of the 4 calls above may have internal calls within the library\n> in order to parse the option for each of the different function which\n> may call these functions)\n\nThis list is a bit too sketchy to be called \"sample api calls\", at\nleast to me.  Can you elaborate a bit more?\n\nWhat do they do, what does the caller expect to see (do they get\nsomething as return values?  do they expect some side effects?)?\n"},{"id":"237336","messageId":"CAM+=D-D=PW=ZJFvc0y+Zhs8tPcbXnP-q4w-MeeLwT+t-QD_55w@mail.gmail.com","threadId":"36253","inReplyTo":"xmqq8us3v42o.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Brian Bourn","fromEmail":"ba.bourn@gmail.com","sentAt":"2014-03-21T18:03:41Z","receivedAt":"2014-03-21T18:03:41Z","isPatch":false,"sender":{"key":"ba.bourn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3165958?v=4"},"body":"On Fri, Mar 21, 2014 at 1:45 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Brian Bourn <ba.bourn@gmail.com> writes:\n>\n>> Something like this?\n>>\n>> Sample api calls\n>> Add_Opt_Group()\n>> Parse_with_contains()\n>> Parse_with_merged()\n>> Parse_with_no_merged()\n>> Parse_with_formatting()\n>> (each of the 4 calls above may have internal calls within the library\n>> in order to parse the option for each of the different function which\n>> may call these functions)\n>\n> This list is a bit too sketchy to be called \"sample api calls\", at\n> least to me.  Can you elaborate a bit more?\n>\n> What do they do, what does the caller expect to see (do they get\n> something as return values?  do they expect some side effects?)?\n\nso something like this would be better I'm assuming?\n\nSome basic sample API calls are found below, each of these would hold\ncode to complete parsing and/or formatting the flags.\nAdd_Opt_Group() - returns an OPT_CALLBACK with contains, merged,\nno-merged, or formatting which can be used in a commands options list.\n\nExecute_list()-the main call into the library and would pass into the\nlibrary all of the necessary flags and arguments for parsing the\nrequest and executing it. This would accept the flags like\n-contain, with arguments such as the commit or pattern that is being\nsearched for.\n\nThe next four commands would be called by execute_list() to execute\nthe original command with respect to the flags that are passed into\nthis library.\nParse_with_contains()\nParse_with_merged()\nParse_with_no_merged()\nParse_with_formatting()\n"},{"id":"237338","messageId":"20140321180745.GB15508@sigill.intra.peff.net","threadId":"36253","inReplyTo":"CAM+=D-D=PW=ZJFvc0y+Zhs8tPcbXnP-q4w-MeeLwT+t-QD_55w@mail.gmail.com","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-21T18:07:45Z","receivedAt":"2014-03-21T18:07:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 21, 2014 at 02:03:41PM -0400, Brian Bourn wrote:\n\n> > What do they do, what does the caller expect to see (do they get\n> > something as return values?  do they expect some side effects?)?\n> \n> so something like this would be better I'm assuming?\n> \n> Some basic sample API calls are found below, each of these would hold\n> code to complete parsing and/or formatting the flags.\n> Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged,\n> no-merged, or formatting which can be used in a commands options list.\n> \n> Execute_list()-the main call into the library and would pass into the\n> library all of the necessary flags and arguments for parsing the\n> request and executing it. This would accept the flags like\n> -contain, with arguments such as the commit or pattern that is being\n> searched for.\n> \n> The next four commands would be called by execute_list() to execute\n> the original command with respect to the flags that are passed into\n> this library.\n> Parse_with_contains()\n> Parse_with_merged()\n> Parse_with_no_merged()\n> Parse_with_formatting()\n\nThink about how the callers would use them. Will git-branch just call\nParse_with_contains? If so, where would that call go? What arguments\nwould it take, and what would it do?\n\nI don't think those calls are enough. We probably need:\n\n  1. Some structure to represent a \"list of refs\" and store its\n     intermediate state.\n\n  2. Some mechanism for telling that structure about the various\n     filters, sorters, and formatters we want to use (and this needs to\n     be hooked into the option-parsing somehow).\n\n  3. Some mechanism for getting the listed refs out of that structure,\n     formatting them, etc.\n\n-Peff\n"},{"id":"237341","messageId":"CAM+=D-DoacQWLuu6XEJzFQXFTaA4UiszJeD5BHJy2zXRFdWKSw@mail.gmail.com","threadId":"36253","inReplyTo":"20140321180745.GB15508@sigill.intra.peff.net","subject":"Re: [RFC] [GSoC] Draft of Proposal for GSoC","fromName":"Brian Bourn","fromEmail":"ba.bourn@gmail.com","sentAt":"2014-03-21T18:35:42Z","receivedAt":"2014-03-21T18:35:42Z","isPatch":false,"sender":{"key":"ba.bourn@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3165958?v=4"},"body":"On Fri, Mar 21, 2014 at 2:07 PM, Jeff King <peff@peff.net> wrote:\n> On Fri, Mar 21, 2014 at 02:03:41PM -0400, Brian Bourn wrote:\n>\n>> > What do they do, what does the caller expect to see (do they get\n>> > something as return values?  do they expect some side effects?)?\n>>\n>> so something like this would be better I'm assuming?\n>>\n>> Some basic sample API calls are found below, each of these would hold\n>> code to complete parsing and/or formatting the flags.\n>> Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged,\n>> no-merged, or formatting which can be used in a commands options list.\n>>\n>> Execute_list()-the main call into the library and would pass into the\n>> library all of the necessary flags and arguments for parsing the\n>> request and executing it. This would accept the flags like\n>> -contain, with arguments such as the commit or pattern that is being\n>> searched for.\n>>\n>> The next four commands would be called by execute_list() to execute\n>> the original command with respect to the flags that are passed into\n>> this library.\n>> Parse_with_contains()\n>> Parse_with_merged()\n>> Parse_with_no_merged()\n>> Parse_with_formatting()\n>\n> Think about how the callers would use them. Will git-branch just call\n> Parse_with_contains? If so, where would that call go? What arguments\n> would it take, and what would it do?\n>\n> I don't think those calls are enough. We probably need:\n>\n>   1. Some structure to represent a \"list of refs\" and store its\n>      intermediate state.\n>\n>   2. Some mechanism for telling that structure about the various\n>      filters, sorters, and formatters we want to use (and this needs to\n>      be hooked into the option-parsing somehow).\n>\n>   3. Some mechanism for getting the listed refs out of that structure,\n>      formatting them, etc.\n\nkeeping some of my function calls to do the actual work I think I\nsettled on this\n\nA possible API is given below, each of these would hold code to\ncomplete parsing and/or formatting the flags.\n\nThere will be a struct in the library called refs_list() which when\ninitialized will iterate through all the refs in a repository and add\nthem to this list.\n\n there would be a function which would retrieve ref structs from that function.\n\nGet_ref_from_list()- which would return a single ref from the list.\n\nAdd_Opt_Group() - returns an OPT_CALLBACK with contains, merged,\nno-merged, or formatting which can be used in a commands options list.\n\nExecute_list()-the main call into the library and would pass into the\nlibrary all of the necessary flags and arguments for parsing the\nrequest and executing it. This would accept the flags like contain,\nwith arguments such as the commit or pattern that is being searched\nfor. This will then parse the refs_list using the four commands below\nto make, sort, filter, and format an output list which will then be\nprinted or returned by this function.\n\nAny Call into the API from an outside source would call one of the\nprevious two functions, all other commands in the API would be for\ninternal use only, in order to simplify the process of calling into\nthis library.\n\nThe next four commands would be called by execute_list() to further\nformat the refs_list with respect to the flags that are passed into\nthis library. These would also take the additional arguments from\nexecute_list() such as patterns to parse or which commit to filter\nout. these calls would modify the refs_list for eventual printing.\n\nParse_list _with_contains()\n\nParse_list_with_merged()\n\nParse_list_with_no_merged()\n\nFormat_list()\n\nof course this would still depend on deciding whether or not we want\nto return to the original command to print or if printing can be\nhandled by the library itself.\n\n\n> -Peff\n"}]}