Hi all, I have attempted a microproject [1][2] and this is my first draft of the proposal.I have included only the matter regarding my approach to solving the problem and shall add my personal details later.
Please be kind enough to go through my proposal and suggest modifications or detailing wherever required. Also give me feedback on whether my approach to solving the problem is correct. In the meantime I am reading up the code of Jeff's attempt at unification,here [3] for preparing my final proposal. -------------------------------------------------------------------------------- Title ----- Unifying git branch -l,git tag -l and git for-each-ref Abstract -------- git for-each-ref and the list modes of git branch and git tag involve selecting a subset of the refs and printing out the result. Currently the implementations are not shared in the sense that :- SELECTION 1. git branch knows --contains,--merged and --no-merged 2. git tag only knows --contains FORMATTING 1. git for-each-ref knows formatting which none of the other two commands know. SORTING 1. git tag knows sorting only on the basis of refnames 2. git for-each-ref knows sorting on the basis of all the fieldnames which can be used in its --format option The idea is to unify the computations for these processes in a common library and teach these commands all these options uniformly. Why do we need unification? These commands try to accomplish more or less the same thing . So,new features would most likely be applicable to all three of them. So, unification will allow us build new features for all these commands in one go instead of doing it separately for each of the three commands. Jeff has already worked quite a bit on unifying the selection part. I shall use that work as a starting point when I start off building the library and its API calls. Deliverables ------------ 1. The unified library will borrow the --contains implementation from git tag (due to the speed up it had received), the --merged/--no-merged implementation from git branch and the --format implementation from git for-each-ref. 2. The commands will then be taught these options by making calls to this library functions and structures. 3. Add documentation and tests for these new features. Optionals --------- 1. Implement the --sort option for these commands in the unified library. 2. Add documentation and tests for this feature Approach -------- The common library will contain a structure which will store the present state of the list of refs in the sense that after we perform a computation(eg. --contains <commit>) on the list of refs, the new list will store the result of that computation. The structure will also have other attributes which the options structure will take in as its (void *)value attribute’s value before parsing the different options. This is to communicate to the structure about the various options(eg. --merged, --format, --sort) we want to use. The list of refs shall be fetched by the API in accordance with the command(eg. git tag) and its option(eg. --merged) which were passed to the API. Next comes the matter of printing out the results according to the format specified (the default format for the command if no format is specified). This will be done in a method similar to how git for-each-ref prints out the results in the given format. Approximate Timeline -------------------- (To estimate the amount of work that can be done in summers though it may change during the project[based on advice from mentors]) May 03 - May 10 Read and understand the implementation of --contains option in git tag and the --merged/--no-merged implementation in git branch. May 11 - May 17 Go through Jeff’s work on unification to get detailed pointers on how to start with unifying selection. Finalise all the structures required and also the API calls the library would have to make for the selection options. May 18 - May 24 Start working on the API. Discuss ideas with mentor, brainstorm on the details of what function calls will be made to the API and what function calls will be made by the API. CODING PERIOD BEGINS May 25 - May 31 Implement the --contains option in the library by taking the cue from how git tag --contains is implemented. June 1 - June 7 Implement the -merge and --no-merged options similar to how they are implemented in git branch June 8 - June 11 Make computations more efficient, improve comments and start documentation. Discuss about additional features and requirements with mentors. June 12 - June 25 Teach the three commands to use the API for formatting and sorting. Add tests and refactor the code of the API if required. Complete the documentation for the new features added. MID-TERM EVALUATION June 26 - June 30 Discuss with mentors about the state and the pace with which the project is coming on. Start finalising the details of the further goals to be accomplished. July 01 - July 07 Start working on the formatting and sorting by going through their code respective codes in git for-each-ref. Put together a list of API calls along with their functionality, which we need to add to the library to implement these features. July 08 - July 21 Implement the --format feature in the library with all the API calls it needs to make July 22 - August 04 Teach the three commands to use the API for formatting and sorting. Improve comments and code readability. Add documentation and tests for all the new features that have been implemented. August 05 - August 16 I have kept these two weeks as a buffer. If a feature is taking more time than expected then I will concentrate on rectifying it. Else, I shall start working on the implementation of the --sort feature in the library by taking the cue from its implementation in git for-each-ref. I shall also add documentation and tests for this SUGGESTED ‘PENCILS DOWN’ DATE After August 16 Submit the project on the GSoC melange website .Try to contribute to projects that fit my skill set and remain active on mailing list. ------------------------------------------------------------------------------------------------- Thanks and regards, R Sundararajan [1] : http://thread.gmane.org/gmane.comp.version-control.git/265695 [2] : http://thread.gmane.org/gmane.comp.version-control.git/265696/focus=265742 [3] : https://github.com/peff/git/commits/jk/for-each-ref-contains-wip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
