My earlier lazy index opening patch changed this condition to check
index_data and call open_pack_index if it was NULL. In truth we only
care about num_objects. Since open_pack_index does no harm if the
index is already open, and all indexes are likely to be closed in
this application, the "performance optimization" of inlining the
index_data check here was wrong.
Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx>
---
First of a 3 part series to cleanup behind the lazy index patch.
This particular one was stupid; the lazy index patch never should
have been submitted with the conditions like this.
After this series, I'm pretty sure we've got everything covered.
Additional eyes from other people wouldn't hurt, but I have gone
through every caller several times now and am pretty sure they
are all correct.
Note that we are *not* safe to unload an index once opened; unlike
the use_pack() interface the index_data interface does not offer a
way for a caller to pin the index_data into memory for the duration
of the block. That's one reason I haven't tried to GC indexes yet.
builtin-count-objects.c | 2 +-
pack-redundant.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index ac65e03..4274ec1 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -111,7 +111,7 @@ int cmd_count_objects(int ac, const char **av, const char *prefix)
for (p = packed_git; p; p = p->next) {
if (!p->pack_local)
continue;
- if (!p->index_data && open_pack_index(p))
+ if (open_pack_index(p))
continue;
packed += p->num_objects;
num_pack++;
diff --git a/pack-redundant.c b/pack-redundant.c
index 0617320..6bc3bdf 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -550,7 +550,7 @@ static struct pack_list * add_pack(struct packed_git *p)
l.pack = p;
llist_init(&l.all_objects);
- if (!p->index_data && open_pack_index(p))
+ if (open_pack_index(p))
return NULL;
base = p->index_data;
--
1.5.2.869.g6b3ba
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
