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 do

[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 Signed-off-by

Re: [PATCH] unblock and unignore SIGPIPE

On Wed, Sep 17, 2014 at 3:11 AM, Jeff King 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 commands indi

Re: [PATCH] unblock and unignore SIGPIPE

On Sun, Aug 17, 2014 at 8:14 PM, Eric Wong 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 unblock it before spawning

[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 --- cache.h

[PATCH v2] use a hashmap to make remotes faster

off-by: Patrick Reynolds --- 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..52533e4 100644 --