git gc leaved my disk 100% full

Jean Delvare· Jan 19, 2016, 16:09 UTC · lore

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

Jeff King· Feb 4, 2016, 07:58 UTC · re: Jean Delvare · lore

Re: git gc leaved my disk 100% full

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

Show 18 quoted lines

> 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