diff options
| author | Thomas Ackermann <th.acker@arcor.de> | 2013-08-27 20:05:50 +0200 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2013-08-27 15:14:46 -0700 |
| commit | ddeb817f25fea45dee5456c48d723e56b9f8991b (patch) | |
| tree | 094fc21039a33346a980de2359fe7c93f285bfca | |
| parent | 381183fbc6c3fea1264e4fc6c977bf31cdfb812a (diff) | |
| download | git-ddeb817f25fea45dee5456c48d723e56b9f8991b.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.txt | 12 |
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 |