Re: [RFC] [GSoC] Draft of Proposal for GSoC

From: Jeff King <peff@peff.net>
Date: Mar 21, 2014, 18:07 UTC
Message-ID: <20140321180745.GB15508@sigill.intra.peff.net>
In-Reply-To: <CAM+=D-D=PW=ZJFvc0y+Zhs8tPcbXnP-q4w-MeeLwT+t-QD_55w@mail.gmail.com>

On Fri, Mar 21, 2014 at 02:03:41PM -0400, Brian Bourn wrote:

Show 23 quoted lines

> > What do they do, what does the caller expect to see (do they get
> > something as return values?  do they expect some side effects?)?
> 
> so something like this would be better I'm assuming?
> 
> Some basic sample API calls are found below, each of these would hold
> code to complete parsing and/or formatting the flags.
> Add_Opt_Group() - returns an OPT_CALLBACK with contains, merged,
> no-merged, or formatting which can be used in a commands options list.
> 
> Execute_list()-the main call into the library and would pass into the
> library all of the necessary flags and arguments for parsing the
> request and executing it. This would accept the flags like
> -contain, with arguments such as the commit or pattern that is being
> searched for.
> 
> The next four commands would be called by execute_list() to execute
> the original command with respect to the flags that are passed into
> this library.
> Parse_with_contains()
> Parse_with_merged()
> Parse_with_no_merged()
> Parse_with_formatting()

Think about how the callers would use them. Will git-branch just call Parse_with_contains? If so, where would that call go? What arguments would it take, and what would it do?

I don't think those calls are enough. We probably need:

  1. Some structure to represent a "list of refs" and store its
     intermediate state.

  2. Some mechanism for telling that structure about the various
     filters, sorters, and formatters we want to use (and this needs to
     be hooked into the option-parsing somehow).

  3. Some mechanism for getting the listed refs out of that structure,
     formatting them, etc.

-Peff