Re: [RFC] [GSoC] Draft of Proposal for GSoC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.bourn@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]