Re: XDL_FAST_HASH can be very slow

I have been working with Peff on this and have more results to share. For background, xdl_hash_record is a hashing function, producing an unsigned long from an input string terminated by either a newline or the end of the mmap'd file. The original xdl_hash_record is essentially DJB hash, which

Re: [PATCH] unblock and unignore SIGPIPE

On Wed, Sep 17, 2014 at 3:11 AM, Jeff King p...@peff.net wrote: Would we want to call it from external C commands, too? For the most part, git.c is the entry point for running git commands, and any sanitizing it does will be inherited by sub-commands. But it _is_ still legal to call dashed

[PATCH v2] unblock and unignore SIGPIPE

world, several real potential callers, including Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE ignored. It is easier and more productive to harden git against this mistake than to clean it up in every potential parent process. Signed-off-by: Patrick Reynolds patrick.reyno

Re: [PATCH] unblock and unignore SIGPIPE

On Sun, Aug 17, 2014 at 8:14 PM, Eric Wong normalper...@yhbt.net wrote: But unicorn would ignore SIGPIPE it if Ruby did not; relying on SIGPIPE while doing any multiplexed I/O doesn't work well. Exactly. Callers block SIGPIPE for their own legitimate reasons, but they don't consistently

[PATCH] unblock and unignore SIGPIPE

world, several real potential callers, including Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE ignored. It is easier and more productive to harden git against this mistake than to clean it up in every potential parent process. Signed-off-by: Patrick Reynolds patrick.reyno

[PATCH v2] use a hashmap to make remotes faster

-by: Patrick Reynolds patrick.reyno...@github.com --- mark function with no arguments as taking void remote.c | 63 ++- remote.h | 3 +++ 2 files changed, 49 insertions(+), 17 deletions(-) diff --git a/remote.c b/remote.c index a0701f6