Thomas Ackermann <th.ac...@arcor.de> writes: > According to the man-pages of "git prune" and "git fsck", > both are safe nowadays.
Safe does not have much to do with the latter. "git fsck" has always been safe in that it would not alter the object store, and if you run it while you are actively creating (or pruning for that matter) objects, it _will_ get confused. For that matter, running "prune", even though we designed it to be safe from concurrent accesses, deliberately on a non-quiescent repository is not a good idea, either. It may be a good idea to weaken the phrasing used to discourage it, but discouraging itself is not a bad idea. > Signed-off-by: Thomas Ackermann <th.ac...@arcor.de> > --- > Documentation/user-manual.txt | 12 +----------- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt > index 08d8c91..29945d9 100644 > --- a/Documentation/user-manual.txt > +++ b/Documentation/user-manual.txt > @@ -3283,17 +3283,7 @@ 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 > -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). > +and they'll be gone. > > [[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
