From: Junio C Hamano <junkio@cox.net>
Date: Sun, 01 May 2005 10:50:44 GMT
Subject: Should git-prune-script warn about dircache?
Message-ID: <7vwtqjxlrv.fsf@assigned-by-dhcp.cox.net>

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?