Re: [PATCH v6 17/19] fsck: Introduce `git fsck --quick`

[Johannes Schindelin <johannes.schindelin@gmx.de>]

Hi Junio,

On 2015-06-21 19:15, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> But now that I'm writing this, a silly question occurs to me: Do we need
>> an overall option like this at all? If I demote all blob-integrity
>> checks to "ignore" via the mechanism that you have added, then shouldn't
>> fsck automatically detect that it doesn't have to open the blobs at all
>> and enable this speedup automatically?
> 
> That's brilliant.
> 
> Just to make sure I am reading you correctly, you mean the current
> overall structure:
> 
> [...]

The way I read Michael's mail, he actually meant something different: if all of the blob-related errors/warnings are switched to "ignore", simply skip unpacking the blobs. If I read this correctly, I would like to point out that introducing a future blob-related check would require scripts to be changed to benefit from the speed-up, unless the `--quick` option is *also* introduced.

The way I read your suggestion, however, was to introduce *yet another* message ID: BAD_BLOB. If that one is turned to "ignore", we simply won't look at blobs' contents at all.

I like that idea, together with:

>> --quick: Skip some expensive checks, dramatically reducing the
>>     runtime of `git fsck`. Currently this is equivalent to
>>     `--no-check-blob-integrity`.

... where this would become `-c fsck.badBlob=ignore`.

>> In the future if we invent other expensive checks we might also add them
>> to the list of things that are skipped by `--quick`.
> 
> Yes, that is doubly brilliant. Taken together with the auto-skipping
> of the checks based on the report settings, it makes it unnecessary
> to even introduce --[no-]check-blob-integrity or any other new
> knobs.
> 
> Very well analysed.  I am happy with the "--quick" with that
> definition.

Did I understand you correctly? If so, I will gladly implement this tomorrow and send out v7.

Ciao,
Dscho