On Fri, Nov 16, 2012 at 1:54 PM, Thomas Gay <tgay@xxxxxxxxxxx> wrote: >> If you set receive.unpacklimit to 1 on the receiving end, does it still crash? > > Yes. The crash log looks the same too. If it still says "unpack-objects died of signal 11" then it was not done the right way. The receiving end can use either unpack-objects or index-pack for storing the objects. I know unpack-objects is not ready for large blobs (though I cannot explain your crash log, that's why I still need you to test it this way). I was hoping to force it use index-pack and see it still crashes. If it does, we have other problems than unpack-objects not being ready for large blobs. If it does not, I'd say it's a known issue with a known solution (I was planning on merging unpack-objects functionality back to index-pack). We can try again this way. index-pack will be used if the number of transfer objects exceeds 100 (by default). You are pusing 16 objects, which is why unpack-objects is used. We can try to push garbage to the other end to meet the 100 limit, then reset the branch at the other end later. You can run "git gc" early on the other end to clean up garbage, or it'll be done automatically at some point in future. Make sure there is no changes in index and worktree, or adjust you may want to change the last four commands slightly. mkdir tmp for i in `seq 200`;do echo $i > tmp/$i; git add $i; done git commit -m 'useless stuff' git push <where?> # should not crash again git reset --hard HEAD^ git push <same-where?-above> -- Duy -- 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