"jones.noamle" [off-list ref] writes:
# git gc
Counting objects: 44626, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7756/7756), done.
fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
space left on device
In general when we encounter an unexpected error, we tend to try
leaving things as they are so that we can help diagnosing the
failure. But when you ran out of disk space I would agree that it
may be sensible to remove a temporary file we didn't manage to write
out in full.
Am 26.02.2013 17:07, schrieb Junio C Hamano:
"jones.noamle" [off-list ref] writes:
quoted
# git gc
Counting objects: 44626, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7756/7756), done.
fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
space left on device
In general when we encounter an unexpected error, we tend to try
leaving things as they are so that we can help diagnosing the
failure. But when you ran out of disk space I would agree that it
may be sensible to remove a temporary file we didn't manage to write
out in full.
Ack. I just recently had to do
git gc || rm -f .git/objects/*/tmp_*
as workaround in the nightly housekeeping script on our CI server.
On Wed, Feb 27, 2013 at 2:01 AM, Jens Lehmann [off-list ref] wrote:
Am 26.02.2013 17:07, schrieb Junio C Hamano:
quoted
"jones.noamle" [off-list ref] writes:
quoted
# git gc
Counting objects: 44626, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7756/7756), done.
fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
space left on device
In general when we encounter an unexpected error, we tend to try
leaving things as they are so that we can help diagnosing the
failure. But when you ran out of disk space I would agree that it
may be sensible to remove a temporary file we didn't manage to write
out in full.
Ack. I just recently had to do
git gc || rm -f .git/objects/*/tmp_*
as workaround in the nightly housekeeping script on our CI server.
it's not just 'git gc'; a failed push of a large repo (failed due to,
say, network issues or whatever) also leave tmp_* lying around. At
least as far as I can tell...
On Wed, Feb 27, 2013 at 05:58:20AM +0530, Sitaram Chamarty wrote:
quoted
Ack. I just recently had to do
git gc || rm -f .git/objects/*/tmp_*
as workaround in the nightly housekeeping script on our CI server.
it's not just 'git gc'; a failed push of a large repo (failed due to,
say, network issues or whatever) also leave tmp_* lying around. At
least as far as I can tell...
Yes, we used to run into problems with failed pushes sometimes at
GitHub. A later `git gc` will clean up the tmp_* objects (via `git
prune`), but of course we will not run the prune if the repack fails.
Also note that a push will just keep receiving objects as long as the
client wishes to send them, spooling straight to disk, before any
enforcement hooks have a chance to run. So on stock git, you could in
theory just fill up the receiver's disk, and then git will leave the
file sitting around.
I have a patch to make index-pack just do a hard hangup after receiving
`receive.maximumBytes` bytes (with an appropriate message to stderr).
It's not an exact measure of the size of the push (since we need to
complete thin packs, and we may also explode smaller packs), but it at
least bounds the size that the sender can push. I'm happy to share the
patch if others are interested (it's only a few lines).
I've also considered a patch to have index-pack clean up tmp_pack_*
automatically on exit, default to off (i.e., the current behavior). A
busy site could turn it on globally, and then shut it off for a specific
repo when trying to debug a push problem. I find that the leftover
tmp_pack files are very seldom of interest for forensic debugging. I
haven't bothered to write that patch, though; we dropped our prune
expiration time well below the 2-week default, so the tmp files get
cleaned up pretty regularly now.
-Peff