On Thu, Oct 12, 2017 at 11:34:39AM +0200, Andreas Krey wrote: > > Does using create_tempfile there seem like a good path forward to you? > > Would you be interested in working on it (either writing a patch with > > such a fix or a test in t/ to make sure it keeps working)? > > I will look into creating a patch (thanks for the pointers), > but I don't see how to make a testcase for this - pre-filling the > disk doesn't sound like a good idea. Most people probably won't run in > this situation, and then won't have tmp_packs with a dozen GBytes each > lying around. It may be easier to trigger a case which rejects the pack for other reasons. For an incoming index-pack, turning on transfer.fsckObjects is an easy one. For a repack, perhaps corrupting a loose object to-be-packed would work. E.g.: git init echo content >file git add file git commit -m foo # corrupt the blob in a subtle way obj=.git/objects/$(git rev-parse HEAD:file | sed 's,..,&/,') chmod +w $obj echo cruft >>$obj After that, I get: $ git repack -ad Counting objects: 3, done. error: garbage at end of loose object 'd95f3ad14dee633a758d2e331151e950dd13e4ed' fatal: loose object d95f3ad14dee633a758d2e331151e950dd13e4ed (stored in .git/objects/d9/5f3ad14dee633a758d2e331151e950dd13e4ed) is corrupt $ find -type f .git/objects/pack .git/objects/pack/tmp_pack_0GaXwk -Peff
