This round adds more explanation in commit message of 2/3 and comment before get_base_data() in 3/3. Changes in 3/3 does not really address Junio's concern regarding maintainability though. It also fixes a regression in 3/3. In current code, get_base_data() goes up as far as the first deflated parent. v2 of this series always goes up to top parent. v3 fixes this. Junio raised a point about depth-first vs breadth-first search in 1/3. I have not addressed that either, but it makes me wonder if we may benefit from using bfs in find_unresolved_deltas(), 2/3. If the delta chains form a fork-like figure (e.g. long delta chains sharing common base), then we may run out of cache doing dfs on one chain, by the time we get back on the common base, we would need to deflate them again. Another observation is recursion in get_base_data() is unlikely to be called in real life. With 16M default delta base cache, git.git does not trigger it at all. Perhaps repos with large blobs have better chance.. Nguyễn Thái Ngọc Duy (3): Eliminate recursion in setting/clearing marks in commit list index-pack: eliminate recursion in find_unresolved_deltas index-pack: eliminate unlimited recursion in get_base_data() builtin/index-pack.c | 164 ++++++++++++++++++++++++++++++++++--------------- commit.c | 13 ++++- revision.c | 45 +++++++++----- 3 files changed, 154 insertions(+), 68 deletions(-) -- 1.7.8.36.g69ee2 -- 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