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

Ævar Arnfjörð Bjarmason 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

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 writes: > >> On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano wrote: >>> If the project has some tool constraints and have to accept new >>> "broken" objects on ongoing basis, then fsck. facility may >>> make sense, but that

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

Junio C Hamano writes: > Between "fsck. 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*

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

Ævar Arnfjörð Bjarmason writes: > On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano wrote: >> If the project has some tool constraints and have to accept new >> "broken" objects on ongoing basis, then fsck. facility may >> make sense, but that is probably a very narrow special use case. > > That

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

On Mon, May 28, 2018 at 11:45 AM, Junio C Hamano wrote: > Eric Sunshine writes: > >>> @@ -1554,23 +1554,42 @@ filter..smudge:: >>> +Depending on the circumstances it might be better to use >>> +`fsck.skipList` instead to explicitly whitelist those

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

Eric Sunshine writes: >> @@ -1554,23 +1554,42 @@ filter..smudge:: >> +Depending on the circumstances it might be better to use >> +`fsck.skipList` instead to explicitly whitelist those objects that >> +have issues, otherwise new occurrences of the same issue will be I

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

On Fri, May 25, 2018 at 3:28 PM, Ævar Arnfjörð Bjarmason wrote: > The documentation for the fsck. and receive.fsck. > variables was mostly duplicated in two places, with fsck. > making no mention of the corresponding receive.fsck., and the > same for fsck.skipList. > [...] >

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

The documentation for the fsck. and receive.fsck. variables was mostly duplicated in two places, with fsck. making no mention of the corresponding receive.fsck., and the same for fsck.skipList. I spent quite a lot of time today wondering why setting the fsck. variant wasn't working to clone a