On Tue, Sep 04, 2018 at 07:36:43PM -0400, Jeff King wrote:
> On Tue, Sep 04, 2018 at 12:38:07PM -0400, Jeff King wrote:
>
> > > And just to be clear I'm looking forward to a patch from Jeff to fix
> > > this since he clearly put more thoughts on this than me. With commit.c
> > > being the only
Jeff King writes:
> On Wed, Sep 05, 2018 at 09:54:42AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> >> > So AFAIK this fsck catches everything and yields a non-zero exit in the
>> >> > error case. And it should work for even a single byte of rubbish.
>> >>
>> >> Yes you're right.
On Wed, Sep 05, 2018 at 09:54:42AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> > So AFAIK this fsck catches everything and yields a non-zero exit in the
> >> > error case. And it should work for even a single byte of rubbish.
> >>
> >> Yes you're right. I forgot about the trailing
Jeff King writes:
>> > So AFAIK this fsck catches everything and yields a non-zero exit in the
>> > error case. And it should work for even a single byte of rubbish.
>>
>> Yes you're right. I forgot about the trailing hash.
>
> Thanks, I was worried that I was missing something. ;)
>
> Maybe it
On Wed, Sep 05, 2018 at 05:39:19PM +0200, Duy Nguyen wrote:
> On Wed, Sep 5, 2018 at 5:35 PM Jeff King wrote:
> > > > + after=$(wc -c <.git/index) &&
> > > > +
> > > > + # double check that the index shrank
> > > > + test $before -gt $after &&
> > > > +
> > > > + # and
On Wed, Sep 5, 2018 at 5:35 PM Jeff King wrote:
> > > + after=$(wc -c <.git/index) &&
> > > +
> > > + # double check that the index shrank
> > > + test $before -gt $after &&
> > > +
> > > + # and that our index was not corrupted
> > > + git fsck
> >
> > If the index
On Wed, Sep 05, 2018 at 05:27:11PM +0200, Duy Nguyen wrote:
> > +test_expect_success PERL 'commit -p with shrinking cache-tree' '
> > + mkdir -p deep/subdir &&
> > + echo content >deep/subdir/file &&
> > + git add deep &&
> > + git commit -m add &&
> > + git rm -r
On Wed, Sep 5, 2018 at 1:36 AM Jeff King wrote:
> It turned out not to be too bad to write a test. It feels a little like
> black magic, since I empirically determined a way in which the
> cache-tree happens to shrink with the current code.
Aha! I attempted to reproduce with a verylongpathname
't think it's important for v2.19.
The patch below should work on master or maint. We could do a fix
directly on top of the bug, but merging-up is weird (because the buggy
code became part of a reusable module).
-- >8 --
Subject: [PATCH] reopen_tempfile(): truncate opened file
We provide a r
9 matches
Mail list logo
