On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Johannes Schindelin <johannes.schindelin@xxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx -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. -- 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