summaryrefslogtreecommitdiff
path: root/t/t8009-blame-vs-topicbranches.sh
diff options
context:
space:
mode:
authorLibravatar Ævar Arnfjörð Bjarmason <avarab@gmail.com>2019-04-07 21:52:17 +0200
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-04-08 17:01:10 +0900
commit0044f7700fdbfdb04b8f88c385ca6fd545e1e1bb (patch)
treea365459b8b9835bf65f312aa1840868cd773cd7c /t/t8009-blame-vs-topicbranches.sh
parentgc docs: clarify that "gc" doesn't throw away referenced objects (diff)
downloadtgif-0044f7700fdbfdb04b8f88c385ca6fd545e1e1bb.tar.xz
gc docs: remove incorrect reference to gc.auto=0
The chance of a repository being corrupted due to a "gc" has nothing to do with whether or not that "gc" was invoked via "gc --auto", but whether there's other concurrent operations happening. This is already noted earlier in the paragraph, so there's no reason to suggest this here. The user can infer from the rest of the documentation that "gc" will run automatically unless gc.auto=0 is set, and we shouldn't confuse the issue by implying that "gc --auto" is somehow more prone to produce corruption than a normal "gc". Well, it is in the sense that a blocking "gc" would stop you from doing anything else in *that* particular terminal window, but users are likely to have another window, or to be worried about how concurrent "gc" on a server might cause corruption. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t8009-blame-vs-topicbranches.sh')
0 files changed, 0 insertions, 0 deletions