git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)

From
Karsten Blees <karsten.blees@gmail.com>
Date
Dec 7, 2013, 19:56 UTC
Message-ID
<52A37D70.3090400@gmail.com>
In-Reply-To
<xmqqk3fh1qrc.fsf@gitster.dls.corp.google.com>
Am 07.12.2013 00:52, schrieb Junio C Hamano:
Show 8 quoted lines
> * kb/doc-exclude-directory-semantics (2013-11-07) 1 commit
>  - gitignore.txt: clarify recursive nature of excluded directories
> 
>  Originally merged to 'next' on 2013-11-13
> 
>  Kicked back to 'pu' to replace with a newer reroll ($gmane/237814
>  looked OK but there seems to have some loose ends in the
>  discussion).
I'm unaware of any loose ends, could you clarify?
Btw. $gmane/237814 seems to be a different topic, the version in next (and now in pu) was $gmane/237429.
> * kb/fast-hashmap (2013-11-18) 14 commits
>   (merged to 'next' on 2013-12-06 at f90be3d) 
Damn, a day too late :-) I found these two glitches today...is a fixup patch OK or should I do a reroll (or separate patch on top)?

Thanks, Karsten

--- 8< ---
Subject: [PATCH] fixup! add a hashtable implementation that supports O(1) removal
Use 'unsigned int' for hash-codes everywhere.

Extending 'struct hashmap_entry' with an int-sized member shouldn't waste memory on 64-bit systems. This is already documented in api-hashmap.txt, but needs '__attribute__((__packed__))' to work. Reduces e.g.

 struct name_entry {
     struct hashmap_entry ent;
     int namelen;
     char *name;
 };
from 32 to 24 bytes.
Signed-off-by: Karsten Blees <blees@dcon.de>
---
 hashmap.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hashmap.h b/hashmap.h
index f5b3b61..b64567b 100644
--- a/hashmap.h
+++ b/hashmap.h
@@ -15,7 +15,7 @@ extern unsigned int memihash(const void *buf, size_t len);
 
 /* data structures */
 
-struct hashmap_entry {
+struct __attribute__((__packed__)) hashmap_entry {
 	struct hashmap_entry *next;
 	unsigned int hash;
 };
@@ -43,7 +43,7 @@ extern void hashmap_free(struct hashmap *map, int free_entries);
 
 /* hashmap_entry functions */
 
-static inline void hashmap_entry_init(void *entry, int hash)
+static inline void hashmap_entry_init(void *entry, unsigned int hash)
 {
 	struct hashmap_entry *e = entry;
 	e->hash = hash;
-- 
1.8.5.1.178.g0a9afc1.dirty
Previous: Matthieu MoyNext: Thomas Rast
Message 9 of 23 in “What's cooking in git.git (Dec 2013, #02; Fri, 6)”
  1. Junio C HamanoDec 6, 2013
  2. Felipe ContrerasDec 7, 2013
  3. Felipe ContrerasDec 7, 2013
  4. Junio C HamanoDec 9, 2013
  5. Thomas RastDec 7, 2013
  6. Jeff KingDec 9, 2013
  7. Junio C HamanoDec 9, 2013
  8. Matthieu MoyDec 7, 2013
  9. Karsten BleesDec 7, 2013
  10. Thomas RastDec 7, 2013
  11. Karsten BleesDec 7, 2013
  12. Thomas RastDec 8, 2013
  13. Karsten BleesDec 9, 2013
  14. Jonathan NiederDec 9, 2013
  15. Karsten BleesDec 9, 2013
  16. Jonathan NiederDec 9, 2013
  17. Karsten BleesDec 18, 2013
  18. Karsten BleesDec 18, 2013
  19. Karsten BleesDec 18, 2013
  20. Junio C HamanoDec 9, 2013
  21. Junio C HamanoDec 9, 2013
  22. hashmap.h: Use 'unsigned int' for hash-codes everywhereKarsten Blees, Dec 18, 2013
  23. Junio C HamanoDec 18, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.