Re: [PATCH v2 2/5] config doc: unify the description of fsck.* and receive.fsck.*

On Wed, May 30 2018, Junio C Hamano wrote:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano [off-list ref] wrote:

quoted

If the project has some tool constraints and have to accept new
"broken" objects on ongoing basis, then fsck.<msg-id> facility may
make sense, but that is probably a very narrow special use case.

That makes sense. I'll reword this bit.
...
I'll try to clarify this, but I think we really should have some bit
there about historical tools. Realistically no new git tools produce
these, so the user needs to be made aware of what the trade-off of
turning these on is.

The reality of that is that these objects are exceedingly rare, and
mostly found in various old repositories. Something like that need to
be mentioned so the user can weigh the trade-off of turning this on.

Rare or not, once we say "avoid fsck.<msg-id> unless you have a good
reason not to", wouldn't that be sufficient?

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.

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.