[BUG] resolved deltas

[Petr Stodulka <pstodulk@redhat.com>]

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