Hi Junio, On 2015-06-21 19:15, Junio C Hamano wrote: > Michael Haggerty <mhag...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in
