[PATCH 0/3] fix data corruption in fast-import

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(-)