Thomas Ackermann <th.ac...@arcor.de> writes: > "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.ac...@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.)
These new two lines are good, but did we lose the mention of "fsck" that will report what is not dangling as dangling and such when run concurrently with other operations? Is that intended? > > [[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
