On Fri, Nov 16, 2012 at 1:54 PM, Thomas Gay t...@tokyois.com 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
