Should git-prune-script warn about dircache?

When the user has a change that is recorded in the dircache but the change has not been committed, git-fsck-cache --unreachable would report blobs and trees (if you have a subdirectory) that are involved.

    $ git-init-db
    defaulting to local storage area
    $ date >foo
    $ git-update-cache --add foo
    $ date | git-commit-tree $(git-write-tree) >.git/HEAD
    Committing initial tree 9061076c3ec10fef339c84f4e0c9e06576d3b7db
    $ date >foo
    $ git-update-cache foo
    $ git-fsck-cache --unreachable $(cat .git/HEAD)
    unreachable blob d8c61e975a591ad5905c7defc567a77fca58f092
    $ git-ls-files --stage
    100644 d8c61e975a591ad5905c7defc567a77fca58f092 0 foo

At this point, if we run git-prune-script with the current head, we would remove the blob, and after that, code that assumes the objects pointed by SHA1s recorded in the dircache are locally available start failing.

    $ git-prune-script
    $ touch foo
    $ git-diff-files -p
    .git/objects/d8/c61e975a591....: No such file or directory
    fatal: unable to read blob object for foo (d8c61e975a591....)

I have a feeling somewhere in the chain from git-prune-script we should have a mechanism to prevent us from losing such blob and trees. I know it should not be in git-fsck-cache, but I have not decided what my suggestions would be for us to do yet.

Maybe a big warning in red ugly bold blinking typeface somewhere in the doc?