summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Ackermann <th.acker@arcor.de>2013-08-27 20:05:50 +0200
committerJunio C Hamano <gitster@pobox.com>2013-08-27 15:14:46 -0700
commitddeb817f25fea45dee5456c48d723e56b9f8991b (patch)
tree094fc21039a33346a980de2359fe7c93f285bfca
parent381183fbc6c3fea1264e4fc6c977bf31cdfb812a (diff)
downloadgit-ta/user-manual.tar.gz
"git prune" is safeta/user-manual
"git prune" is safe in case of concurrent accesses to a repository but using it in such a case is not recommended. Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
-rw-r--r--Documentation/user-manual.txt12
1 files changed, 3 insertions, 9 deletions
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index b7c725679b..29552e7710 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3299,17 +3299,11 @@ state, you can just prune all unreachable objects:
$ git prune
------------------------------------------------
-and they'll be gone. But you should only run `git prune` on a quiescent
+and they'll be gone. (You should only run `git prune` on a quiescent
repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-
-(The same is true of `git fsck` itself, btw, but since
-`git fsck` never actually *changes* the repository, it just reports
-on what it found, `git fsck` itself is never 'dangerous' to run.
-Running it while somebody is actually changing the repository can cause
-confusing and scary messages, but it won't actually do anything bad. In
-contrast, running `git prune` while somebody is actively changing the
-repository is a *BAD* idea).
+`git prune` is designed not to cause any harm in such cases of concurrent
+accesses to a repository but you might receive confusing or scary messages.)
[[recovering-from-repository-corruption]]
Recovering from repository corruption