On Wed, 31 Aug 2005 13:13:56 -0700 Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Stephen Rothwell <[EMAIL PROTECTED]> 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
> 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
> 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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html