On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > >> On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano <gits...@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? 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.
