[BUG] resolved deltas

Hi guys, I wanted post you patch here for this bug, but I can't find primary source of this problem [0], because I don't understand some ideas in the code. So what I investigate:

Bug is reprodusible since git version 1.8.3.1 (may earlier 1.8.xx, but I don't test it) to actual upstream version. This problem "doesn't exists" in version 1.7.xx - or more precisely is not reproducible. "May" this is reproducible since commit "7218a215" - in this commit was added assert in file "builtin/index-pack.c" (actual line is 918), but I didn't test this.

This assert tests if object's (child) real type == OBJ_REF_DELTA. This will failure for object with real_type == OBJ_TREE (set as parent's type) and type == OBJ_REF_DELTA. Here some prints of important variables before failure assert() (from older version but I think that values are still actual in this case): ------------------------------ (gdb) p base->ref_first $9 = 3223

(gdb) p deltas[3223]
$10 = {
   base = {
     sha1 = "\274\070k\343K\324x\037q\273h\327*n\n\356\061$ \036",
     offset = 2267795834784135356
   },
   obj_no = 11152
}

(gdb) p *child
$11 = {
   idx = {
     sha1 = "J\242i\251\261\273\305\067\236%CE\022\257\252\342[;\tD",
     crc32 = 2811659028,
     offset = 10392153
   },
   size = 30,
   hdr_size = 22,
   type = OBJ_REF_DELTA,
   real_type = OBJ_TREE,
   delta_depth = 0,
   base_object_no = 5458
}

(gdb) p objects[5458]
$13 = {
   idx = {
     sha1 = "\274\070k\343K\324x\037q\273h\327*n\n\356\061$ \036",
     crc32 = 3724458534,
     offset = 6879168
   },
   size = 236,
   hdr_size = 2,
   type = OBJ_TREE,
   real_type = OBJ_TREE,
   delta_depth = 0,
   base_object_no = 0
}
---------------------------------------

"base_object_no" is static 5458. "base->ref_first" child's object are dynamic. If you want stop process in same position my recommendation for gdb (if you use gdb) when you will be in file index-pack.c: br 1093 cont set variable nr_threads = 1 br 1111 cond 2 i == 6300 cont br 916 cont ----------- compilated without any optimisation, line numbers modified for commit "6c4ab27f2378ce67940b4496365043119d7ffff2" Condition i == 6300 ---> last iteration before failure has dynamic rank in range 6304 to 6309 in the most cases (that's weird for me, when count of downloaded objects is statically 12806, may wrong search of children?) -----------------------------------

Here I am lost. I don't know really what I can do next here, because I 
don't understand some ideas in code. e.g. searching of child - functions 
find_delta(), find_delta_children(). Calculation on line 618:
----
     int next = (first+last) / 2;
----
I still don't understand. I didn't find description of this searching 
algorithm in tech. documentation but I didn't read all yet. However I 
think that source of problems could be somewhere in these two functions. 
When child is found, its real_type is set to parent's type in function 
resolve_delta() on the line 865 and then lasts wait for failure. I don't 
think that problem is in repository itself [1], but it is possible.

Any next ideas/hints or explanation of these functions? I began study source code and mechanisms of the git this week, so don't beat me yet please :-)

Regards, Petr

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1099919 [1] git clone https://code.google.com/p/mapsforge/ mapsforge.git