From: Thomas Ackermann Date: Sat, 24 Aug 2013 07:37:52 GMT Subject: [PATCH 13/13] "git prune" is safe now Message-ID: <1590776724.1091303.1377329872606.JavaMail.ngmail@webmail08.arcor-online.net> In-Reply-To: <282216171.1090748.1377328932833.JavaMail.ngmail@webmail08.arcor-online.net> According to the man-pages of "git prune" and "git fsck", both are safe nowadays. Signed-off-by: Thomas Ackermann --- 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