Hello again, Please it would be very helpful for me to get some comments on this proposal I would be very grateful towards anyone who could take some time to look at it, even if it's just the wording. Regards, Brian Bourn
On Thu, Mar 20, 2014 at 2:15 PM, Brian Bourn <ba.bo...@gmail.com> wrote: > Hi all, > > This is a first draft of my Proposal for GSoC, I'd love feedback about > what I might be missing and any other files I should read regarding > this, so far I have read most of tag.c, branch.c, > builtin/for-each-ref.c, parse-options.c. once again I hope I can get > the same amount of helpful feedback as when I submitted my > Microproject. > > My name is Brian Bourn, I'm currently a computer engineering student > at Columbia university in the city of New York. I've used git since > my freshman year however this past week has been my first time > attempting to contribute to the project, and I loved it. I'd > particularly like to tackle Unifying git branch -l, git tag -l, and > git for-each-ref. This functionality seems like an important update > to me as it will simplify usage of git throughout three different > commands, a noble pursuit which is not contained in any other project. > > 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] > > 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, > > 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 > > Next I would implement these flags in the three files so that they are > uniform and the same formatting and list capabilities can be used on > all three. The formatting option will be especially useful for branch > and tag as it will allow users to better understand what is in each > ref that they grab. > > For the most part I haven't finalized my weekly schedule but a basic > breakdown would be > > Start-Midterm > Begin deprecation of -l > Spend some time reading *.c files even deeper > Build Library(dedicate Minimum one week per function moved) > > Midterm-finish > Implement the list flags > Implement the format flags > (if time is left over, add some formatting) > > Additionally I am thinking about adding some more formatting tools > such as numbering outputs. What do you all think of this? > > > [1]http://git.661346.n2.nabble.com/More-formatting-with-git-tag-l-tt6739049.html > > [2]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6725483 > > [3]http://git.661346.n2.nabble.com/RFC-PATCH-tag-make-list-exclude-lt-pattern-gt-tt7270451.html#a7338712 > > > [4]http://git.661346.n2.nabble.com/RFC-branch-list-branches-by-single-remote-tt6645679.html#a6728878 > > [5]http://git.661346.n2.nabble.com/RFC-PATCH-0-2-RFC-POC-patterns-for-branch-list-tt6309233.html > > [6]https://github.com/git/git/blob/master/builtin/branch.c#L817 > > [7] https://github.com/git/git/blob/master/builtin/branch.c#L849 > > [8] https://github.com/git/git/blob/master/builtin/branch.c#L843 > > Regards, > Brian Bourn -- 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
