[PATCH v2 4/5] config doc: mention future aspirations for transfer.fsckObjects

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

Jeff King has said on at least a couple of occasions (at least one of
which may have been in person over beer) that leaving corrupt objects
in the local object store after a "fetch" that fails
transfer.fsckObjects should be fixed, and we should have something
like the server-side quarantine environment on the client-side.

Let's note that in the documentation so we don't seem to be claiming
that this is by design. A previous version of this change called the
current behavior a "bug", that's probably too strong a claim, but I
don't think anyone would dislike a hypothetical local quarantine
patch, so let's we might change this in the future.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Documentation/config.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 71b3805b4e..f97f21c022 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -3350,7 +3350,9 @@ security checks may be added in future releases.
 On the receiving side, failing fsckObjects will make those objects
 unreachable, see "QUARANTINE ENVIRONMENT" in
 linkgit:git-receive-pack[1]. On the fetch side, malformed objects will
-instead be left unreferenced in the repository.
+instead be left unreferenced in the repository. That difference in
+behavior should not be relied upon. In the future, such objects may be
+quarantined for "fetch" as well.
 
 transfer.hideRefs::
 	String(s) `receive-pack` and `upload-pack` use to decide which
-- 
2.17.0.290.gded63e768a