Finally the bug reported first in [1] is solved and has a small testcase. Preliminary attempts can be found in [2] for curious. And the actual "3/3: fix" comes from [3]. Brief introduction. While testing huge imports produced by svn-fe I've found a "failed to unpack delta" error in fast-import, which is actually caused by "sha1 mismatch" error in a packfile, and this one is caused by a bug of producing wrong deltas for tree objects in fast-import. Looks like that only 'M 040000 sha1_or_mark path' commands could trigger it. They were introduced in tags/v1.7.3-rc0~75^2 (30 Jun 2010 334fba65.. Teach fast-import to import subtrees named by tree id) This series should resolve the bug for any copy/rename/set/delete trees scenario anyway. I've tested it on a gcc svn repository import - went fine, trees match the gcc git mirror on github. One more test is ~700k commits from kde repository - fine too. 1/3 just extracts a sha1 calculation function for 2/3 2/3 adds a die() for "corrupted" delta data and a testcase that triggers it 3/3 is the fix [1] http://thread.gmane.org/gmane.comp.version-control.git/176753 [2] http://thread.gmane.org/gmane.comp.version-control.git/178007 [3] http://thread.gmane.org/gmane.comp.version-control.git/176753/focus=178053 Dmitry Ivankov (3): fast-import: extract object preparation function fast-import: add a check for tree delta base sha1 fast-import: prevent producing bad delta fast-import.c | 85 +++++++++++++++++++++++++++++++++++++++--------- t/t9300-fast-import.sh | 38 +++++++++++++++++++++ 2 files changed, 107 insertions(+), 16 deletions(-) -- 1.7.3.4 -- 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