Stefan Beller venit, vidit, dixit 25.02.2015 01:34: > 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. I guess they've read about the lkml too much :) I consider the gitml to be a relatively civilized place for constructive criticism, without rants, flame wars and ad hominem swear word attacks. I don't know how it's perceived from the outside (but that drew me in back then). Maybe we can attach a photo of our maintainer to the GSOC page? That would prove we're nice and polite :) > 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. Yes, the technical workflow as well as the "social habits". They should follow the gitml even before, and then the micro projects are a great learning ground. Michael -- 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