James Bowes [off-list ref] writes:
find_short_packed_object was not loading the pack index files.
Teach it to do so.
Signed-off-by: James Bowes <redacted>
I think this is the proper fix of the problem I was unhappy
about with 'next', rather than reverting the lazy index
loading. But I wonder how many _other_ places like this there
are that we might be missing...
Shawn, an Ack, and any ideas for futureproofing?
quoted hunk
sha1_name.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 8dfceb2..7df01af 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -76,8 +76,11 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
prepare_packed_git();
for (p = packed_git; p && found < 2; p = p->next) {
- uint32_t num = p->num_objects;
- uint32_t first = 0, last = num;
+ uint32_t num, last;
+ uint32_t first = 0;
+ open_pack_index(p);
+ num = p->num_objects;
+ last = num;
while (first < last) {
uint32_t mid = (first + last) / 2;
const unsigned char *now;--
1.5.2.869.g6b3ba
Junio C Hamano [off-list ref] wrote:
James Bowes [off-list ref] writes:
quoted
find_short_packed_object was not loading the pack index files.
Teach it to do so.
Signed-off-by: James Bowes <redacted>
I think this is the proper fix of the problem I was unhappy
about with 'next', rather than reverting the lazy index
loading. But I wonder how many _other_ places like this there
are that we might be missing...
Shawn, an Ack, and any ideas for futureproofing?
Ack, though late. ;-)
I actually found this exact same bug today. At first I thought it
was related to alternates, but when I dug into the code I came up
with basically the same patch as James did. His was sent in first
and is logically identical, so I'm not going to send my version.
With regards to future proofing this, I have no idea. I'm going to
write up a test case that catches this and submit that, to avoid a
future regression here, but otherwise I'm not sure what we can do.
I had thought I had visited every callsite and checked them, but
apparently that wasn't true.
What would probably help is to change the name of the structure
member in the .h file when its initialization time changes (or its
meaning changes in a subtle way) and then go through and manually
update every mention of the old name to the new name, then flip it
back with a global search and replace when done.
E.g. I should have done:
* in cache.h rename num_objects to num_objects_SHAWNCHANGEHERE;
* manually update every num_objects usage to my private name;
* finally globally search-replace back to the standard name.
It would have forced me to more carefully visit every damn callsite.
I'll go back through the code tonight and double check my work,
because this bug was completely my fault. I'm hoping this was the
only bug however.
--
Shawn.
Junio C Hamano [off-list ref] wrote:
James Bowes [off-list ref] writes:
quoted
find_short_packed_object was not loading the pack index files.
Teach it to do so.
Signed-off-by: James Bowes <redacted>
I think this is the proper fix of the problem I was unhappy
about with 'next'
Actually this bug is exactly the reason why I *always* run 'next'
in production use on all of my systems, and why I also get a number
of coworkers to run it. Many people beating on the same code in
weird ways notice things.
Today I found this because I have a shell script that tried to
do something of the form "git checkout v1.8.0-18-g18as1f' and Git
couldn't believe that was a revision... It held up day-job work
for an hour while I tracked it down, but I did catch it. ;-)
--
Shawn.