Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > It's our documentation that should be clearly stating those reasons. If > we're not saying anything about these being historical bugs, then e.g. I > (not knowing the implementation) wouldn't have turned this on globally > on my site knowing that because I have none of these now I'm *very* > unlikely to have them in the future. > > That's different from something that just happens rarely, because a rare > non-historical event can be expected to happen in the future.
Interesting. If I did not know Git at all, I would decide completely opposite---because I have none of these now, I'm very unlikely to have them in the future, so I would leave fsck.<msg-id> alone to the generally recommended state (i.e. not customizing without understanding what I am doing). That way, (1) if that unlikely thing happens, I would notice and have a chance to deal with it, and (2) otherwise, I wouldn't have to worry about that unlikely event at all. And that decision would not change even if I _knew_ these knobs' categories were invented to align with bugs and anomalies in older implementations of Git. > >> Between "fsck.<msg-id> makes sense only when you use these rare and >> you-probably-never-heard-of tools ongoing basis" and "when you >> already have (slightly)broken objects, naming each of them in >> skiplist, rather than covering the class, is better because you want >> *new* instances of the same breakage", I'd imagine the latter would be >> more helpful. >> >> In any case, let's see if there are more input to this topic and >> then wrap it up in v3 ;-) >> >> Thanks.
