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.
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

Reply via email to