Re: What's cooking in git.git (Oct 2013, #06; Fri, 25)
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Oct 26, 2013, 10:30 UTC
- Message-ID
- <CACsJy8A3s4TUmUOC+i-k97GxxvBQ7mQmdoPJizfy1yS3rqLEkA@mail.gmail.com>
- In-Reply-To
- <xmqqeh79hr3o.fsf@gitster.dls.corp.google.com>
On Sat, Oct 26, 2013 at 6:23 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
> * kb/fast-hashmap (2013-10-22) 12 commits > - remove old hash.[ch] implementation > - read-cache.c: fix memory leaks caused by removed cache entries > - name-hash.c: remove cache entries instead of marking them CE_UNHASHED > - name-hash.c: use new hash map implementation for cache entries > - name-hash.c: remove unreferenced directory entries > - name-hash.c: use new hash map implementation for directories > - diffcore-rename.c: use new hash map implementation > - diffcore-rename.c: simplify finding exact renames > - diffcore-rename.c: move code around to prepare for the next patch > - buitin/describe.c: use new hash map implementation > - add a hashtable implementation that supports O(1) removal > - submodule: don't access the .gitmodules cache entry after removing it > > Improvements to our hash table to get it to meet the needs of the > msysgit fscache project, with some nice performance improvements. > > The preparatory clean-up to submodule from Jens is at the bottom. I > also squashed in a fix-up by Karsten found at $gmane/236468 (please > double-check the result).
jk/pack-bitmap adds khash.h, which from a first glance looks like yet another hash table implementation. I was just wondering if kb's new hash tables can cover the need of pack-bitmap.c too so we can remove khash.h later..
-- Duy