On Thu, May 24, 2018 at 3:35 PM, Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> The existing documentation led the user to believe that all we were
> doing were basic readability sanity checks, but that hasn't been true
> for a very long time. Update the description to match reality, and
> note the caveat that there's a quarantine for accepting pushes, but
> not for fetching.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -3339,9 +3339,19 @@ transfer.fsckObjects::
> -When set, the fetch or receive will abort in the case of a malformed
> -object or a broken link. The result of an abort are only dangling
> -objects.
> +When set, the fetch receive will abort in the case of a malformed
"fetch receive"? Did you mean "fetch or receive" (like the original)?
> +object or a link to a nonexisting object. In addition, various other
s/nonexisting/nonexistent/
> +issues are checked for, including legacy issues (see `fsck.<msg-id>`),
> +and potential security issues like there being a `.GIT` directory (see
s/there being/existence of/
> +the release notes for v2.2.1 for details). Other sanity and security
> +checks may be added in future releases.
> ++
> +On the receiving side failing fsckObjects will make those objects
s/side/&,/
> +unreachable, see "QUARANTINE ENVIRONMENT" in
> +linkgit:git-receive-pack[1]. On the fetch side the malformed objects
s/side/&,/
> +will instead be left unreferenced in the repository. That's considered
> +a bug, and hopefully future git release will implement a quarantine
> +for the "fetch" side as well.
If this was a "BUGS" section in a man-page, the above might be less
scary. In this context, however, I wonder if it makes sense to tone it
down a bit:
On the fetch side, malformed objects will instead be left
unreferenced in the repository. (However, in the future, such
objects may be quarantined for "fetch", as well.)
