Am 03.12.2013 19:21, schrieb Jeff King:
On Tue, Dec 03, 2013 at 03:40:41PM +0100, Karsten Blees wrote:
IMO, trying to improve khash isn't worth the trouble.
With smaller-than-pointer types, khash _may_ actually save a few bytes
compared to hash.[ch] or hashmap.[ch]. E.g. a set of 'int's
Am 28.11.2013 11:38, schrieb Jeff King:
On Wed, Nov 27, 2013 at 10:08:56AM +0100, Karsten Blees wrote:
Khash is OK for sha1 keys, but I don't think it should be advertised
as a second general purpose hash table implementation. Its far too
easy to shoot yourself in the foot by using
On Tue, Dec 03, 2013 at 03:40:41PM +0100, Karsten Blees wrote:
IMO, trying to improve khash isn't worth the trouble.
With smaller-than-pointer types, khash _may_ actually save a few bytes
compared to hash.[ch] or hashmap.[ch]. E.g. a set of 'int's would be a
perfect use case for khash.
On Fri, Nov 29, 2013 at 10:21:04PM +0100, Thomas Rast wrote:
I do think it's worth fixing the syntax pedantry at the end so that we
can keep supporting arcane compilers, but otherwise, meh.
Agreed. I've picked up those changes in my tree.
+static int open_pack_bitmap_1(struct packed_git
Jeff King p...@peff.net writes:
I do wonder if at some point we should revisit our do not use any
C99-isms philosophy. It was very good advice in 2005. I don't know how
good it is over 8 years later (it seems like even ancient systems should
be able to get gcc compiled as a last resort, but
On Mon, Dec 02, 2013 at 12:36:34PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I do wonder if at some point we should revisit our do not use any
C99-isms philosophy. It was very good advice in 2005. I don't know how
good it is over 8 years later (it seems like even
Jeff King p...@peff.net writes:
Sorry, I was not very clear about what I said. I do not think go get a
newer gcc is a good thing to be telling people. But I wonder:
a. if there are actually people on systems that have pre-c99 compilers
in 2013
b. if there are, do they actually
TLDR: nitpicks. Thanks for a very nice read.
I do think it's worth fixing the syntax pedantry at the end so that we
can keep supporting arcane compilers, but otherwise, meh.
+static int open_pack_bitmap_1(struct packed_git *packfile)
This goes somewhat against the naming convention (if you
On Wed, Nov 27, 2013 at 10:08:56AM +0100, Karsten Blees wrote:
Khash is OK for sha1 keys, but I don't think it should be advertised
as a second general purpose hash table implementation. Its far too
easy to shoot yourself in the foot by using 'straightforward' hash-
and comparison functions.
Am 24.11.2013 22:36, schrieb Thomas Rast:
Jeff King p...@peff.net writes:
[...]
I think I'll also lend you a hand writing
Documentation/technical/api-khash.txt
(expect it tomorrow) so that we also have documentation in the git
style, where gitters can be expected to find it on their own.
Jeff King p...@peff.net writes:
khash.h | 338
[...]
diff --git a/khash.h b/khash.h
new file mode 100644
index 000..57ff603
--- /dev/null
+++ b/khash.h
@@ -0,0 +1,338 @@
+/* The MIT License
+
+ Copyright (c) 2008, 2009, 2011 by Attractive Chaos
From: Vicent Marti tan...@gmail.com
A bitmap index is a `.bitmap` file that can be found inside
`$GIT_DIR/objects/pack/`, next to its corresponding packfile, and
contains precalculated reachability information for selected commits.
The full specification of the format for these bitmap indexes can
12 matches
Mail list logo