From: Stephen Rothwell <git@ozlabs.org>
Date: Thu, 01 Sep 2005 02:02:26 GMT
Subject: Re: bug in git-fsck-cache?
Message-ID: <20050901120226.54547107.git@ozlabs.org>
In-Reply-To: <7v4q959857.fsf@assigned-by-dhcp.cox.net>

On Wed, 31 Aug 2005 13:13:56 -0700 Junio C Hamano <junkio@cox.net> wrote:
>
> 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.

ok, with '--full' nothing gets reported as dangling.  That commit is not
in a pack, but is in an object directory referenced through
objects/info/alternates.

> 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?

yes, master == origin and that commit is reachable from master according
to gitk.

> 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'.

It is still reachable as fsck-cache --full shows (I guess).

Cheers,
Stephen Rothwell