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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 24, 2015 at 6:19 PM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> 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
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]