Re: [PATCH] reopen_tempfile(): truncate opened file

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2018, 17:01 UTC
Message-ID: <xmqqr2i7515r.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180905165625.GA31930@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 25 quoted lines

> On Wed, Sep 05, 2018 at 09:54:42AM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> 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 is worth making that final comment:
>> >
>> >   # and that the trailing hash in the index was not corrupted,
>> >   # which should catch even a single byte of cruft
>> >   git fsck
>> 
>> Perhaps.  I do not mind seeing an additional comment to explain why
>> this requires PERL (it wasn't immediately obvious as I never use
>> 'commit -p' myself), either.
>
> I thought the PERL prereq in the existing "-p" test of the commit header
> would explain it. ;)
>
> Do you prefer an in-code comment, or one in the commit message?

Neither ;-)

Just like I think 'our index was not corrupted' as an explanation for 'git fsck' is sufficient, PERL sprinkled all over this script and all of them tend to be near "commit -i/-p" should be a good enough clue, I'd think.