Paul Tan pyoka...@gmail.com writes:
I think it's still good to have the ideal in mind though (and whoops I
forgot to put in the word ideal in the text).
Using or not using fork is merely one of the trade-offs we can make.
If all other things are equal, no fork is better than a fork is a
On 24.03.2015 17:37, Paul Tan wrote:
I'm applying for git in the Google Summer of Code this year. For my
project, I propose to rewrite git-pull.sh and git-am.sh into fast
optimized C builtins. I've already hacked up a prototype of a builtin
git-pull in [1], and it showed a promising 8x
On Thu, Mar 26, 2015 at 1:54 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
I think it's still good to have the ideal in mind though (and whoops I
forgot to put in the word ideal in the text).
Using or not using fork is merely one of the trade-offs we can
Hi,
On Wed, Mar 25, 2015 at 2:37 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
..., I propose the following requirements for the rewritten code:
1. No spawning of external git processes. This is to support systems with
high
``fork()`` or process
Hi all,
I'm applying for git in the Google Summer of Code this year. For my
project, I propose to rewrite git-pull.sh and git-am.sh into fast
optimized C builtins. I've already hacked up a prototype of a builtin
git-pull in [1], and it showed a promising 8x improvement in execution
time on
On Tue, Mar 24, 2015 at 6:19 PM, Matthieu Moy
matthieu@grenoble-inp.fr 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
Paul Tan pyoka...@gmail.com writes:
..., I propose the following requirements for the rewritten code:
1. No spawning of external git processes. This is to support systems with high
``fork()`` or process creation overhead, and to reduce redundant IO by
taking advantage of the internal
Paul Tan pyoka...@gmail.com writes:
On Tue, Mar 24, 2015 at 6:19 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
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
8 matches
Mail list logo
