[PATCH 13/13] "git prune" is safe now

From

Thomas Ackermann <th.acker@arcor.de>

Date

Aug 24, 2013, 07:37 UTC

Message-ID

<1590776724.1091303.1377329872606.JavaMail.ngmail@webmail08.arcor-online.net>

In-Reply-To

<282216171.1090748.1377328932833.JavaMail.ngmail@webmail08.arcor-online.net>

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
 Documentation/user-manual.txt | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 08d8c91..29945d9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3283,17 +3283,7 @@ 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
-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).
+and they'll be gone. 
 
 [[recovering-from-repository-corruption]]
 Recovering from repository corruption

-- 
1.8.3.msysgit.0


---
Thomas