{"thread":{"id":"1704","subject":"bug in git-fsck-cache?","startedAt":"2005-08-31T06:15:29Z","lastAt":"2005-09-01T02:21:02Z","messageCount":4,"participants":["Stephen Rothwell","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7966","messageId":"20050831161529.327a7957.git@ozlabs.org","threadId":"1704","inReplyTo":null,"subject":"bug in git-fsck-cache?","fromName":"Stephen Rothwell","fromEmail":"git@ozlabs.org","sentAt":"2005-08-31T06:15:29Z","receivedAt":"2005-08-31T06:15:29Z","isPatch":false,"sender":{"key":"git@ozlabs.org","avatar":null},"body":"Hi all,\n\nI have a tree that is a copy of Linus' git kernel tree in which I have\nbeen doing development and pulling updates and rebasing my patches etc.\n\nIt now does this:\n\n$ git fsck-cache\ndangling tree 34d23b379f39922dff3cee671e28d41f3be56167\ndangling blob 3eab2290b12a2cb683e4eadc20253bde37c84859\ndangling blob 578e30193b7b67b71da1bdf0e822b8d783d8c245\ndangling blob 7798f01f77b4aeacfd14586e9847deee1bf7ca74\ndangling blob 81e94f8aa84684862edacb2fafff9cf9dca6878d\ndangling blob 85420bb37d581bc725d07c34254e4a3a1a834038\ndangling tree 908ef958d87158278502966ed4f941478e18c5d7\ndangling blob 93c437a0911b9d00d4ce76be30686144e8063f5e\ndangling tree 9c14b3618c3977e7ea58d25632585543e56f5e09\ndangling tree b8c7a5af99058a82dab51eb7b27ad81987ffa5df\ndangling tree c004aeb8be7b0520174174e574d2655a610844a8\ndangling commit c594adad5653491813959277fb87a2fef54c4e05\ndangling blob d0960a82708cad4196c2d44f0a16cb3e80f77c00\ndangling tree ed4e5baf7854719c19177988eb864b9be5867fa7\ndangling tree ede09c2983717a0ad040e9c79f37dcb801fe49b6\ndangling tree f0f3c408b22634fbd5c6409610c566ae7c92ddc3\n$ git prune\n$ git fsck-cache\ndangling tree 34d23b379f39922dff3cee671e28d41f3be56167\ndangling blob 3eab2290b12a2cb683e4eadc20253bde37c84859\ndangling blob 578e30193b7b67b71da1bdf0e822b8d783d8c245\ndangling blob 7798f01f77b4aeacfd14586e9847deee1bf7ca74\ndangling blob 81e94f8aa84684862edacb2fafff9cf9dca6878d\ndangling blob 85420bb37d581bc725d07c34254e4a3a1a834038\ndangling tree 908ef958d87158278502966ed4f941478e18c5d7\ndangling blob 93c437a0911b9d00d4ce76be30686144e8063f5e\ndangling tree 9c14b3618c3977e7ea58d25632585543e56f5e09\ndangling tree b8c7a5af99058a82dab51eb7b27ad81987ffa5df\ndangling tree c004aeb8be7b0520174174e574d2655a610844a8\ndangling commit c594adad5653491813959277fb87a2fef54c4e05\ndangling blob d0960a82708cad4196c2d44f0a16cb3e80f77c00\ndangling tree ed4e5baf7854719c19177988eb864b9be5867fa7\ndangling tree ede09c2983717a0ad040e9c79f37dcb801fe49b6\ndangling tree f0f3c408b22634fbd5c6409610c566ae7c92ddc3\n$\n\nThe commit c594adad5653491813959277fb87a2fef54c4e05 is shown as\n\"connected\" (in Linus' tree, not one of my patches) by gitk, so I am happy\nthat git prune did not get rid of it, but why does fsck-cache report it as\ndangling?\n\nEven stranger, I actually pull Linus' tree into another tree that I have\nnever otherwise modified and I pull updates to my work tree from it.\nfsck-cache finds not problems in the pristine tree.\n\nCheers,\nStephen Rothwell\n"},{"id":"7981","messageId":"7v4q959857.fsf@assigned-by-dhcp.cox.net","threadId":"1704","inReplyTo":"20050831161529.327a7957.git@ozlabs.org","subject":"Re: bug in git-fsck-cache?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-31T20:13:56Z","receivedAt":"2005-08-31T20:13:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Rothwell writes:\n\n> The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as\n> \"connected\" (in Linus' tree, not one of my patches) by gitk, so I am happy\n> that git prune did not get rid of it, but why does fsck-cache report it as\n> dangling?\n\nHmph. You ran fsck-cache by hand without --full (i.e. you told\nit not to worry about objects already in packs); 'git prune'\nruns it with '--full' to do the full connectivity analysis. I\nthink that's where the difference comes from.\n\nIs that commit reachable from any of the refs hanging under your\n$GIT_DIR/refs/? For example, do you have the Linus tip of the\nmaster branch in $GIT_DIR/refs/heads/origin?\n\nIf an object is already in a pack and later became unreachable\nfrom any of your refs, there is no way to remove that object\nfrom the pack, so dangling commits in a pack will be left\ndangling even after 'git prune'.\n\nOriginally, the distinction between with and without --full was\nmade so that once you fsck and repack, you do not have to spend\ntime doing full object integrity analysis (I think it still does\nfull reachability analysis, but I have to check). It might be\nbetter to remove '--full' option from fsck-cache and make the\ndefault ot do full integrity, and introduce '--fast' option to\nskip it, that is, to default on the safe side.\n"},{"id":"7983","messageId":"20050901120226.54547107.git@ozlabs.org","threadId":"1704","inReplyTo":"7v4q959857.fsf@assigned-by-dhcp.cox.net","subject":"Re: bug in git-fsck-cache?","fromName":"Stephen Rothwell","fromEmail":"git@ozlabs.org","sentAt":"2005-09-01T02:02:26Z","receivedAt":"2005-09-01T02:02:26Z","isPatch":false,"sender":{"key":"git@ozlabs.org","avatar":null},"body":"On Wed, 31 Aug 2005 13:13:56 -0700 Junio C Hamano wrote:\n>\n> Stephen Rothwell writes:\n> \n> > The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as\n> > \"connected\" (in Linus' tree, not one of my patches) by gitk, so I am happy\n> > that git prune did not get rid of it, but why does fsck-cache report it as\n> > dangling?\n> \n> Hmph. You ran fsck-cache by hand without --full (i.e. you told\n> it not to worry about objects already in packs); 'git prune'\n> runs it with '--full' to do the full connectivity analysis. I\n> think that's where the difference comes from.\n\nok, with '--full' nothing gets reported as dangling. That commit is not\nin a pack, but is in an object directory referenced through\nobjects/info/alternates.\n\n> Is that commit reachable from any of the refs hanging under your\n> $GIT_DIR/refs/? For example, do you have the Linus tip of the\n> master branch in $GIT_DIR/refs/heads/origin?\n\nyes, master == origin and that commit is reachable from master according\nto gitk.\n\n> If an object is already in a pack and later became unreachable\n> from any of your refs, there is no way to remove that object\n> from the pack, so dangling commits in a pack will be left\n> dangling even after 'git prune'.\n\nIt is still reachable as fsck-cache --full shows (I guess).\n\nCheers,\nStephen Rothwell\n"},{"id":"7984","messageId":"7vacix5y0h.fsf@assigned-by-dhcp.cox.net","threadId":"1704","inReplyTo":"20050901120226.54547107.git@ozlabs.org","subject":"Re: bug in git-fsck-cache?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-01T02:21:02Z","receivedAt":"2005-09-01T02:21:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Rothwell writes:\n\n>> Stephen Rothwell writes:\n>> \n>> > The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as\n>> > \"connected\" (in Linus' tree, not one of my patches) by gitk, so I am happy\n>> > that git prune did not get rid of it, but why does fsck-cache report it as\n>> > dangling?\n>> \n>> Hmph. You ran fsck-cache by hand without --full (i.e. you told\n>> it not to worry about objects already in packs); 'git prune'\n>> runs it with '--full' to do the full connectivity analysis. I\n>> think that's where the difference comes from.\n>\n> ok, with '--full' nothing gets reported as dangling. That commit is not\n> in a pack, but is in an object directory referenced through\n> objects/info/alternates.\n\nAhh. Yes, it is the same thing. I said \"not in the pack\", but I\nshould have said \"exists locally unpacked\".\n"}]}