"git prune" is safe
"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>
Thomas Ackermann committed
Aug 27, 2013 at 20:05 UTC
ddeb817f25fea45dee5456c48d723e56b9f8991b
1 file changed
+3
-9
Documentation/user-manual.txt
+3
-9
@@ -3299,17 +3299,11 @@ state, you can just prune all unreachable objects:
3299
$ git prune
3300
------------------------------------------------
3301
3302
-and they'll be gone. But you should only run `git prune` on a quiescent
3302
+and they'll be gone. (You should only run `git prune` on a quiescent
3303
repository--it's kind of like doing a filesystem fsck recovery: you
3304
don't want to do that while the filesystem is mounted.
3305
-
3306
-(The same is true of `git fsck` itself, btw, but since
3307
-`git fsck` never actually *changes* the repository, it just reports
3308
-on what it found, `git fsck` itself is never 'dangerous' to run.
3309
-Running it while somebody is actually changing the repository can cause
3310
-confusing and scary messages, but it won't actually do anything bad. In
3311
-contrast, running `git prune` while somebody is actively changing the
3312
-repository is a *BAD* idea).
3305
+`git prune` is designed not to cause any harm in such cases of concurrent
3306
+accesses to a repository but you might receive confusing or scary messages.)
3307
3308
[[recovering-from-repository-corruption]]
3309
Recovering from repository corruption