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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html