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@xxxxxxxxx> --- 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
