Re: [PATCH 11/11] "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>
> ---
>  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.)