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