undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki 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 $ 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 repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted. don't want to do that while the filesystem is mounted.
`git prune` is designed not to cause any harm in such cases of concurrent
(The same is true of `git fsck` itself, btw, but since accesses to a repository but you might receive confusing or scary messages.)
`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).
[[recovering-from-repository-corruption]] [[recovering-from-repository-corruption]]
Recovering from repository corruption Recovering from repository corruption