Re: [msysGit] Re: [RFH] GSoC 2015 application

[Stefan Beller <sbeller@google.com>]

On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
>> Hi Junio,
>>
>> On 2015-02-24 19:25, Junio C Hamano wrote:
>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>> About the proposal:
>>>>
>>>>   The idea of this project is to dive into the Git source code and
>>>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>>>   code, making it a so-called "built-in".
>>>>
>>>> My advice would be to try converting several small scripts, and avoid
>>>> targetting a big one....
>>>> add--interactive and stash are relatively complex beasts, perhaps
>>>> git-pull.sh would be easier to start with.
>>>
>>> Yeah, I think that is a very good suggestion.
>>
>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.
>
> To get an idea, I counted the lines of code written by the student I
> mentored last year:
>
> $ git log --author tanayabh@gmail.com -p | diffstat -s
>  43 files changed, 1225 insertions(+), 367 deletions(-)
>
> I would consider this GSoC as "average" (i.e. not exceptionnally good,
> but certainly not a bad one either), so you may hope for more, but you
> should not _expect_ much more IMHO.
>
> In comparison:
>
> $ wc -l git-add--interactive.perl
> 1654 git-add--interactive.perl
> $ wc -l git-stash.sh
> 617 git-stash.sh
>
> I'd expect a rewrite in C to at least double the number of lines of
> code, so rewriting git-stash would mean writting at least as many lines
> of code as the GSoC above. git-add--interactive.perl would be rather far
> above.
>
> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
> starting with this one and plan more. Then, depending on how it goes,
> you can adjust the target.
>
> This all depends on what you intend to do if the student does not finish
> the job. If you're going to do the rewrite yourself anyway, then having
> the student do even half of it is good already. If you're not going to
> finish the job by yourself, then a 95%-done-rewrite means a piece of
> code posted on the mailing list and never merged (and a lot of time
> wasted).
>
> In any case, these are just advices, certainly not objections or hard
> requests to change.
>


Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a
shell script before. I did not have much real-coding expertise with the
git community before and by today there are 403 lines of code in
builtin/repack.c. so going for roughly 3 times (1200 lines of code) change
would make a summer, specially if you need to learn how the workflow
is in the open source world.  There the lines in c doubled nearly exactly.
(before 197 shell lines, afterwards 387 c lines).

Just last weekend I met people, who were afraid of contributing to open source
"because sometimes the internet can be very mean". Git being quite a high
profile project, as it is widely used, might not help, but rather fear
people away.
That said I would not underestimate the initial time a student needs to learn
the workflow. Though most of that learning is done in the micro project phase.