Parts of v2, once again, i'd love some more comments on what I've rewritten On Fri, Mar 21, 2014 at 1:42 AM, Jeff King <peff@xxxxxxxx> wrote: > 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? > Something like this? Sample api calls Add_Opt_Group() Parse_with_contains() Parse_with_merged() Parse_with_no_merged() Parse_with_formatting() (each of the 4 calls above may have internal calls within the library in order to parse the option for each of the different function which may call these functions) >> 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. This one I can absolutely understand, I tried to break this part down into very managable parts and give myself a little time at the end of each coding period to clean up each previous section. this slop time also allows for me to hopefully add some of the extra features that have been thought of. I'm thinking something like this makes it a little better, Weekly Schedule Start-Midterm Week 1- Begin deprecation of -l in git branch/establish exactly how long each stage of the deprecation should take. Spend some time reading *.c files even deeper while getting to know any current patches occurring in any area near my work files. Lastly, this week will be spent going through the Mailing-list finding previous work done in this area and any other experimental patches Week 2- Move Opt_Group callbacks for the functions into Library Week 3-Make a Contains Function in the library which will work for all three functions Week 4-Add Merge function in library Week 5-Add a No Merge function in library Weeks 7-8 spend time polishing the library and cleaning up the patches for final submission of library to the project Deliverables for midterm- Library finished pending polish and acceptance into the git repository Midterm Week 9- refactor all files to use the contains flag from the file. Week 10- use Merge from library in all relevant files Week 11-use no-merge from library in all relevant files Week 11-12- implement the format flags in all relevant files (this will be slightly harder as I think this might involve calling for-each-ref in the code for tag and branch. Ultimately there is a chance that part of the code for doing for-each-ref will end up in this library as well), additionally add in the code for formatting the relevant opt_Groups into the necessary files. Week 13-14 Polish patches via mailing-list and clean up all the refactoring of the files that has occurred.(optionally, add more formatting changes such as negative patterns and numbering each output into the library). Deliverables for Final- working library hopefully added into the code, and all of the relevant patches for using the library mostly polished and, minimally, pending peer review for submission into the code base. I do wonder if this plan might be a little on the conservative side, if anything, I think this could take a slightly shorter time than planned, but In that case I can always work on other additions to format. > >> 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