Re: bug in git-fsck-cache?
Stephen Rothwell <[EMAIL PROTECTED]> writes: >> 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. Ahh. Yes, it is the same thing. I said "not in the pack", but I should have said "exists locally unpacked". - 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
Re: bug in git-fsck-cache?
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
Re: bug in git-fsck-cache?
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. 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. - 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
bug in git-fsck-cache?
Hi all, I have a tree that is a copy of Linus' git kernel tree in which I have been doing development and pulling updates and rebasing my patches etc. It now does this: $ git fsck-cache dangling tree 34d23b379f39922dff3cee671e28d41f3be56167 dangling blob 3eab2290b12a2cb683e4eadc20253bde37c84859 dangling blob 578e30193b7b67b71da1bdf0e822b8d783d8c245 dangling blob 7798f01f77b4aeacfd14586e9847deee1bf7ca74 dangling blob 81e94f8aa84684862edacb2fafff9cf9dca6878d dangling blob 85420bb37d581bc725d07c34254e4a3a1a834038 dangling tree 908ef958d87158278502966ed4f941478e18c5d7 dangling blob 93c437a0911b9d00d4ce76be30686144e8063f5e dangling tree 9c14b3618c3977e7ea58d25632585543e56f5e09 dangling tree b8c7a5af99058a82dab51eb7b27ad81987ffa5df dangling tree c004aeb8be7b0520174174e574d2655a610844a8 dangling commit c594adad5653491813959277fb87a2fef54c4e05 dangling blob d0960a82708cad4196c2d44f0a16cb3e80f77c00 dangling tree ed4e5baf7854719c19177988eb864b9be5867fa7 dangling tree ede09c2983717a0ad040e9c79f37dcb801fe49b6 dangling tree f0f3c408b22634fbd5c6409610c566ae7c92ddc3 $ git prune $ git fsck-cache dangling tree 34d23b379f39922dff3cee671e28d41f3be56167 dangling blob 3eab2290b12a2cb683e4eadc20253bde37c84859 dangling blob 578e30193b7b67b71da1bdf0e822b8d783d8c245 dangling blob 7798f01f77b4aeacfd14586e9847deee1bf7ca74 dangling blob 81e94f8aa84684862edacb2fafff9cf9dca6878d dangling blob 85420bb37d581bc725d07c34254e4a3a1a834038 dangling tree 908ef958d87158278502966ed4f941478e18c5d7 dangling blob 93c437a0911b9d00d4ce76be30686144e8063f5e dangling tree 9c14b3618c3977e7ea58d25632585543e56f5e09 dangling tree b8c7a5af99058a82dab51eb7b27ad81987ffa5df dangling tree c004aeb8be7b0520174174e574d2655a610844a8 dangling commit c594adad5653491813959277fb87a2fef54c4e05 dangling blob d0960a82708cad4196c2d44f0a16cb3e80f77c00 dangling tree ed4e5baf7854719c19177988eb864b9be5867fa7 dangling tree ede09c2983717a0ad040e9c79f37dcb801fe49b6 dangling tree f0f3c408b22634fbd5c6409610c566ae7c92ddc3 $ 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? Even stranger, I actually pull Linus' tree into another tree that I have never otherwise modified and I pull updates to my work tree from it. fsck-cache finds not problems in the pristine tree. 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
