Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Stefan,

On Tue, 16 Feb 2016, Stefan Beller wrote:

> I'd be interested to co-mentor a sh->C conversion.
> 
> I think the git-rebase*.sh is a good start.
> 
> $ wc -l git-rebase*.sh
>   101 git-rebase--am.sh
>  1296 git-rebase--interactive.sh
>   167 git-rebase--merge.sh
>   636 git-rebase.sh
>  2200 total
> 
> So start with rebase--am and rebase--merge to have the same amount
> of lines as git-pull.sh. I did not look at the code, just judging by
> the lines of
> code.
> 
> git-rebase.sh with 636 lines of code is quite a lot I would think.

As pointed out by Matthieu, starting with `git-rebase.sh` would be the
wrong way round.

In addition, I would like to point out that turning shell scripts into
builtins is not only hard work, it is also very dull. Maybe we can offer
GSoC students something more exciting, and *just maybe* they'll stick
around longer (I am amazed how active Karthik is, for example).

> Then there is also git-bisect.sh with nearly 700 lines, which is also
> not as easy.

Nothing is easy, but bisect has a much better chance to be finally
converted into a builtin: there is already a bisect--helper builtin, and
all we need to do is to move more parts over, piece by piece. It does not
even have to be a complete rewrite.

I count 22 functions with bisect_start and bisect_replay being the obvious
elephants. Personally, I would recommend starting with bisect_next_check
(which would imply get_terms and bisect_voc, of course). It could even be
a mini project for a prospective student.

Ciao,
Johannes