Starting on a microproject for GSoC

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

 



Hi git developers,

the next Google Summer of Code is not too far away. I expect git to
apply for it and hopefully have some student spots which in turn I plan
to apply. It was recommended elsewhere and on this list as well, that it
is beneficial to engage with the community early, that's why I am
writing to you already now, before all this formal stuff has begun.

Before I may introduce myself: I'm a Computer Science student in
Germany, coming towards the end of my Masters. I am an enthusiastic git
user that's why I'd like to give something back. This would be my first
time to actually contribute to a FOSS project and I am quite excited
(also a bit frightened ;)).

As the list of available microprojects 2016 is still to be created, I
might need your help in finding a project to work on. I started to dig
through the archives along items of the list of 2015 [0] and so far
found out the following:

The first task, to make "git -C '' cmd" not to barf seems to be solved.
I tried it with "git -C '' status" at least. I could not find the
related patch, maybe it did use other keywords. I would be interested.

The second task, to allow "-" as a short-hand for "@{-1}" in more places
seems to be still open for reset, although someone almost finished it
(cf. $gmane/265417). I suppose just fixing/revising this would be kind
of a too low hanging fruit? More interesting (also because I am a bit
earlier) might be to unify everything, as suggested by Junio in
$gmane/265260. Or implementing it for another branch command, e.g. rebase.

The other tasks I did not yet dig into.

If all of that is considered as not relevant, I might just go for a
newer idea, like converting strbuf_getline_lf() callers to
strbuf_getline(), as suggested in $gmane/284104.

Any thoughts?

A question regarding the process of "taking a task (or bug)" in general:
Is it solely organized through the mailing list? Suppose I start to work
on something, should I announce it to not risk work duplication? Does it
happen often that more people accidentally work on the same task?

Best,
Moritz

[0] http://git.github.io/SoC-2015-Microprojects.html
--
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]