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

From: Junio C Hamano <gitster@pobox.com>
Date: May 30, 2018, 03:05 UTC
Message-ID: <xmqqr2ltetcy.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CACBZZX5mSj2=JXtVPrPZ8Y1gCyu9p+EMYoSPeFZtuvm3FsdLNg@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 15 quoted lines

> On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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?

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.