Thomas Ackermann th.ac...@arcor.de writes:
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.ac...@arcor.de
---
Documentation/user-manual.txt | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 9149846..ea843e6 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.)
These new two lines are good, but did we lose the mention of fsck
that will report what is not dangling as dangling and such when run
concurrently with other operations? Is that intended?
[[recovering-from-repository-corruption]]
Recovering from repository corruption
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
