Moritz Neeb <lists@xxxxxxxxxxxxx> writes:
> 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.
It is unknown if we are going to participate in GSoC this year. One
question you must ask yourself first: will you still be interested
in hacking Git if we decide not to take GSoC students this year?
The GSoC microprojects are not about seeing who writes great code.
What we want to see primarily with them is how well candidates
interact with the community, responding to reviewers, showing
agreement or disagreement with received comments, making arguments
in a constructive way when opinions differ, updating their
submissions with suggested improvements in a timely matter to keep
the ball rolling, etc. GSoC micros are primarily designed to be
small and can be finished within a short timeframe, but expected to
still have enough iterations with reviewers that candidates can use
as an opportunity to demonstrate how well they can work with the
community.
Suppose a candidate already tackled a micro, went through multiple
iterations with reviewers and came up with a polished solution.
When another candidate comes late and sends in a very similar
"answer" to the same micro, without meaningful interactions with the
reviewers and the community, the latter candidate would not be
demonstrating how good a "fit" s/he is in the community at all.
On the other hand, if the latter candidate approaches the same micro
somebody else attacked in a different way, s/he would have his or
her own interactions with the reviewers and would be demonstrating
his or her ability to work with us.
So in that sense, they are not "quiz" that has a single right
answer, and we do not necessarily have problems if multiple
candidates attack the same micro.
Now, if your answer to the "first" question is "No", then you might
want to avoid wasting your effort investing too early in preparing
for an event that may not happen. You may want to stop reading here
and wait until GSoC micros are posted (if we decide to participate
this year, that is).
If the answer is "Yes", then welcome to the Git development
community ;-)
The purpose of GSoC micro I explained above also means that people
like you, who are interested in hacking Git, can start early and do
their own things to demonstrate that they can work well with our
community, which may give them a head start. When they apply to be
a GSoC student (if we participate this year), we would already have
enough datapoint to convince ourselves that it would be a good idea
to pick them (even without them doing GSoC micro).
> 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.
This actually is a very tricky one to do well.
> 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.
It is a good sign that you are familiar with a recent list
discussion. There are other "once this topic settles, we would
probably want to do this and that kind of cleanups on top" left
behind that haven't made my "leftover bits" page (which I update
only after the discussion dies on the list and there is no sign that
others will be picking them up soonish).
Have fun.
--
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