git gc leaved my disk 100% full

git gc leaved my disk 100% full

[Jean Delvare]

Hi git developers,

Earlier today my desktop environment warned me that my /home was almost
full. I thought that running "git gc" on my git trees would maybe save
some disk space.

Unfortunately the opposite happened. "git gc" failed on me with:

fatal: sha1 file '.git/objects/pack/tmp_idx_XW7opV' write error: No space left on device
error: failed to run repack

and at that point the partition was 100% full. My git repository went
from 2.2 GB to 3.3 GB in the process, this is why.

While I understand the value of preserving temporary files for
debugging purpose, I don't think it makes sense in the context of the
"gc" command which precisely should get rid of such temporary files.

So please consider fixing "gc" so that it cleans up any temporary file
in case of failure.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: git gc leaved my disk 100% full

[Jeff King]

On Tue, Jan 19, 2016 at 05:09:57PM +0100, Jean Delvare wrote:

> Earlier today my desktop environment warned me that my /home was almost
> full. I thought that running "git gc" on my git trees would maybe save
> some disk space.
> 
> Unfortunately the opposite happened. "git gc" failed on me with:
> 
> fatal: sha1 file '.git/objects/pack/tmp_idx_XW7opV' write error: No space left on device
> error: failed to run repack
> 
> and at that point the partition was 100% full. My git repository went
> from 2.2 GB to 3.3 GB in the process, this is why.
> 
> While I understand the value of preserving temporary files for
> debugging purpose, I don't think it makes sense in the context of the
> "gc" command which precisely should get rid of such temporary files.
> 
> So please consider fixing "gc" so that it cleans up any temporary file
> in case of failure.

I agree that it would be nice to auto-clean failed object creation. Or
at least make it a configurable option. We have hacky patches at GitHub
to do so unconditionally, as we ran into problems with failed pushes
piling up.

I didn't send it upstream, because it involved building against a
separate and ugly tempfile API. Now that we have tempfile.[ch] upstream,
I think it wouldn't be too hard to do with register_tempfile().

-Peff