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 '
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.
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 's
Jeff King 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 _use_ th
On Mon, Dec 02, 2013 at 12:36:34PM -0800, Junio C Hamano wrote:
> Jeff King 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 s
Jeff King 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 maybe the
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
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 ca
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 function
Am 24.11.2013 22:36, schrieb Thomas Rast:
> Jeff King 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.
>
Khash
Jeff King 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
> +
> + Pe
From: Vicent Marti
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 be found
in `Doc
12 matches
Mail list logo
