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

[Jeff King <peff@peff.net>]

On Thu, Mar 20, 2014 at 02:15:29PM -0400, Brian Bourn wrote:

> Going through the annals of the listserve thus far I've found a few
> discussions which provide some insight towards this process as well as
> some experimental patches that never seem to have made it
> through[1][2][3][4]

Reading the past work in this area is a good way to get familiar with
it. It looks like most of the features discussed in the threads you link
have been implemented. The one exception seems to be negative patterns.
I think that would be a good feature to build on top of the unified
implementation, once all three commands are using it.

> I would start by beginning a deprecation plan for git branch -l very
> similar to the one Junio presents in [5], moving -create-reflog to -g,

That makes sense. I hadn't really considered "-l" as another point of
inconsistency between the commands, but it definitely is.

> Following this I would begin the real work of the project which would
> involve moving the following flag operations into a standard library
> say 'list-options.h'
> 
> --contains [6]
> --merged [7]
> --no-merged[8]
> --format
> This Library would build these options for later interpretation by parse_options

Can you sketch out what the API would look like for this unified
library? What calls would the 3 programs need to make into it?

> For the most part I haven't finalized my weekly schedule but a basic
> breakdown would be

Can you go into more detail here? Remember that writing code is only one
part of the project. You'll need to be submitting your work, getting
review and feedback, and iterating on it.

One problem that students have is queuing up a large amount of work to
send to the list. Then they twiddle their thumbs waiting for review to
come back (which takes a long time, because they just dumped a large
body of work on the reviewers). If you want to make effective use of
your time, it helps to try to break tasks down into smaller chunks, and
think about the dependencies between the chunks. When one chunk is in
review, you can be designing and coding on another.

> Additionally I am thinking about adding some more formatting tools
> such as numbering outputs. What do you all think of this?

Something like numbering might make sense as part of the formatting code
(e.g., a new placeholder that expands to "n" for the nth line of
output). I think that would be fairly straightforward, but again, it
makes sense to me to unify the implementations first, and then we can
build new features on top.

-Peff