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

From: Paul Tan <pyokagan@gmail.com>
Date: Mar 24, 2015, 17:22 UTC
Message-ID: <CACRoPnRBBVGt8PVHVEYct46abLMJvKf0+MNz7bX2nx2C7OHd3Q@mail.gmail.com>
In-Reply-To: <20150324163730.GA8366@yoshi.chippynet.com>

On Tue, Mar 24, 2015 at 6:19 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 7 quoted lines

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

Show 9 quoted lines

> 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