mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-31 06:17:56 +01:00
Code Activity

"git prune" is safe

Browse source 
"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>
This commit is contained in:
Thomas Ackermann 2013-08-27 20:05:50 +02:00 committed by Junio C Hamano
parent 381183fbc6
commit ddeb817f25
1 changed files with 3 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
Documentation/user-manual.txt
View file

@ -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