I have mentioned this patch series on the mailing list a couple of time [1,2] but haven't submitted it before. I just rebased it to current master. It is available from my Git fork [3] as branch "submodule-hash".
The first point of this patch series is to optimize submodule `ref_store` lookup by storing the `ref_store`s in a hashmap rather than a linked list. But a more interesting second point is to weaken the 1:1 relationship between submodules and `ref_stores` a little bit more. A `files_ref_store` would be perfectly happy to represent, say, the references *physically* stored in a linked worktree (e.g., `HEAD`, `refs/bisect/*`, etc) even though that is not the complete collection of refs that are *logically* visible from that worktree (which includes references from the main repository, too). But the old code was confusing the two things by storing "submodule" in every `ref_store` instance. So push the submodule attribute down to the `files_ref_store` class (but continue to let the `ref_store`s be looked up by submodule). The last commit is relatively orthogonal to the others; it simplifies read_loose_refs() by calling resolve_ref_recursively() directly using the `ref_store` instance that it already has in hand, rather than indirectly via the public wrappers. Michael [1] http://public-inbox.org/git/341999fc-4496-b974-c117-c18a2fca1...@alum.mit.edu/ [2] http://public-inbox.org/git/37fe2024-0378-a974-a28d-18a89d3e2...@alum.mit.edu/ [3] https://github.com/mhagger/git Michael Haggerty (5): refs: store submodule ref stores in a hashmap refs: push the submodule attribute down register_ref_store(): new function files_ref_store::submodule: use NULL for the main repository read_loose_refs(): read refs using resolve_ref_recursively() refs.c | 93 ++++++++++++++++++++++++++++++++++------------------ refs/files-backend.c | 77 +++++++++++++++++++++++++------------------ refs/refs-internal.h | 37 ++++++++------------- 3 files changed, 122 insertions(+), 85 deletions(-) -- 2.9.3
