Re: bug in git-fsck-cache?

From: Junio C Hamano <junkio@cox.net>
Date: Aug 31, 2005, 20:13 UTC
Message-ID: <7v4q959857.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050831161529.327a7957.git@ozlabs.org>

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.