Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> Hrm, setting diff.renamelimit to 0 lets me reproduce (I thought I tried >> it before, but clearly not...). > > Hmph. But I wonder why this part does not trigger, even when > you have renamelimit set to 0. > > /* > * This basically does a test for the rename matrix not > * growing larger than a "rename_limit" square matrix, ie: > * > * rename_dst_nr * rename_src_nr > rename_limit * rename_limit > * > * but handles the potential overflow case specially (and we > * assume at least 32-bit integers) > */ > if (rename_limit <= 0 || rename_limit > 32767) > rename_limit = 32767; > if (rename_dst_nr > rename_limit && rename_src_nr > rename_limit) > goto cleanup; > if (rename_dst_nr * rename_src_nr > rename_limit * rename_limit) > goto cleanup; > > I wonder if the second one for the overflow avoidance should be > using || instead of &&, though. Reverting d19fbe8a7 means coming up with a 3-way merge between d19fbe8a7^ and master as if d19fbe8a7 is their common ancestor. "git diff --name-status d19fbe8a7 d19fbe8a7^" shows only two paths changed. "git diff --name-status d19fbe8a7 master" shows 8558 new paths and 3756 deleted paths, which makes 32m paths pairs, that is still lower than 32767 squared. If your int is 64-bit, struct diff_score which is 4-int is 16-byte long. 32m * 16 = 501,801,600. That seems to match your 450MB observation well. - 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
