On Thu, Oct 12, 2017 at 11:34:39AM +0200, Andreas Krey wrote:
> > Does using create_tempfile there seem like a good path forward to you?
> > Would you be interested in working on it (either writing a patch with
> > such a fix or a test in t/ to make sure it keeps working)?
>
> I will look into
On Wed, Oct 11, 2017 at 08:17:03PM -0700, Jonathan Nieder wrote:
> I can imagine this behavior of retaining tmp_pack being useful for
> debugging in some circumstances, but I agree with you that it is
> certainly not a good default.
>
> Chasing this down, I find:
>
>
On Thu, Oct 12, 2017 at 11:34:39AM +0200, Andreas Krey wrote:
> On Wed, 11 Oct 2017 20:17:03 +, Jonathan Nieder wrote:
> > Does using create_tempfile there seem like a good path forward to you?
> > Would you be interested in working on it (either writing a patch with
> > such a fix or a test
On Wed, 11 Oct 2017 20:17:03 +, Jonathan Nieder wrote:
> Hi Andreas,
>
> Andreas Krey wrote:
>
> > I observed (again) an annoying behavior of 'git repack':
>
> Do you have context for this 'again'? E.g. was this discussed
> previously on-list?
I think I posted about it, but no discussion.
Hi Andreas,
Andreas Krey wrote:
> I observed (again) an annoying behavior of 'git repack':
Do you have context for this 'again'? E.g. was this discussed
previously on-list?
> When the new pack file cannot be fully written because
> the disk gets full beforehand, the tmp_pack file isn't
>
Hi all,
I observed (again) an annoying behavior of 'git repack':
When the new pack file cannot be fully written because
the disk gets full beforehand, the tmp_pack file isn't
deleted, meaning the disk stays full:
$ df -h .; git repack -ad; df -h .; ls -lart .git/objects/pack/tmp*; rm
6 matches
Mail list logo
