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 -- 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