Re: [RFC/GSoC] Proposal: Make git-pull and git-am builtins

On Tue, Mar 24, 2015 at 6:19 PM, Matthieu Moy
[off-list ref] wrote:

A few minor details:

"on operating systems with poor file system performance (i.e. Windows)"
=> that's not only windows, I also commonly use a slow filesystem on
Linux, just because it's NFS. Mentionning other cases of poor filesystem
performance would show that the benefit is not limited to windows users,
and would give less of a taste of "windows-bashing".

Ah right, I didn't think of network file systems. Thanks for the suggestion.

About the timeline: I'd avoid too much parallelism. Usually, it's best
to try to send a first patch to the mailing list as soon as possible,
hence focus on one point first (I'd do that with pull, since that's the
one which is already started). Then, you can parallelize coding on git
am and the discussion on the pull patches. Whatever you plan, review and
polishing takes more than that ;-). The risk is to end up with an almost
good but not good enough to be mergeable code. That said, your timeline
does plan patches and review early, so I'm not too worried.

Well, I was thinking that after the full rewrite (2nd stage, halfway
through the project), any optimizations made to the code will be done
iteratively (and in separate small patches) so as to keep the patch
series in an "always almost mergeable" state. This will hopefully make
it much easier and shorter to do any final polishing and review for
merging.

A general advice: if time allows, try to contribute to discussions and
review other than your own patches. It's nice to feel integrated in the
community and not "the GSoC student working alone at home" ;-).

Yeah I apologize for not participating in the list so actively because
writing the git-pull prototype and the proposal took a fair chunk of
my time. Also, my expertise with the code base is not that great yet
so it takes quite a bit more effort for me to contribute
constructively, but I expect that will improve in the future. Now that
the proposal is more or less complete I can spend more time on
discussions.

Thanks,
Paul