Re: bug in git-fsck-cache?

[Junio C Hamano <junkio@cox.net>]

Stephen Rothwell <git@ozlabs.org> writes:

> The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as
> "connected" (in Linus' tree, not one of my patches) by gitk, so I am happy
> that git prune did not get rid of it, but why does fsck-cache report it as
> dangling?

Hmph.  You ran fsck-cache by hand without --full (i.e. you told
it not to worry about objects already in packs); 'git prune'
runs it with '--full' to do the full connectivity analysis.  I
think that's where the difference comes from.

Is that commit reachable from any of the refs hanging under your
$GIT_DIR/refs/?  For example, do you have the Linus tip of the
master branch in $GIT_DIR/refs/heads/origin?

If an object is already in a pack and later became unreachable
from any of your refs, there is no way to remove that object
from the pack, so dangling commits in a pack will be left
dangling even after 'git prune'.

Originally, the distinction between with and without --full was
made so that once you fsck and repack, you do not have to spend
time doing full object integrity analysis (I think it still does
full reachability analysis, but I have to check).  It might be
better to remove '--full' option from fsck-cache and make the
default ot do full integrity, and introduce '--fast' option to
skip it, that is, to default on the safe side.