{"thread":{"id":"1824","subject":"git fsck messages - what to do about it?","startedAt":"2005-09-16T10:11:38Z","lastAt":"2005-09-18T22:13:41Z","messageCount":9,"participants":["Wolfgang Denk","Catalin Marinas","Petr Baudis","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8668","messageId":"20050916101138.99906352682@atlas.denx.de","threadId":"1824","inReplyTo":null,"subject":"git fsck messages - what to do about it?","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-09-16T10:11:38Z","receivedAt":"2005-09-16T10:11:38Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"When running git fsck I get some messages:\n\n-> git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*)\nunreachable commit 08cf4121ad704faa5ae7c7ae7b3dca4476ef2770\nunreachable tree 29a4c18afd958cc6cee938f0fe7fa59764418097\nunreachable tree 3b722a7278e02b272ddc8aefbc7be22703d8a94f\nunreachable tree 4ebc50d240d99b4236952d13d5044691f9078e3c\nunreachable tree 63af5944e130b449338cc907ee77c51f4a69e339\nunreachable tree 79c9a6bb02a80df15c7d829bdac0901f88c5e301\nunreachable blob 85dcf4b5c4c0f6833cd63fa1d0fd29ef250162af\nunreachable commit c1b779fbce762c970e3ace4332bb6ddc0de65e61\nunreachable blob d70d1d44f12db7b2a3976c2a5313c90568a62c25\nunreachable commit e1bcd2a5d53bceef2679737474487e32d87e7f2c\n\nI have to admit that I don't know what to do next...\n\na) I understand that these  messages  are  indications  of  problems,\n   right? What can I do to clean this up?\n\nb) Is there any way to find out what I did wrong in the first place?\n\nIn case it matters: the tree in question is available at\n{rsync,http}://source.denx.net/git/u-boot.git\n\nThanks in advance,\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering:  Embedded and Realtime Systems,  Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\n\"This isn't brain surgery; it's just television.\"   - David Letterman\n"},{"id":"8670","messageId":"tnx3bo59tm8.fsf@arm.com","threadId":"1824","inReplyTo":"20050916101138.99906352682@atlas.denx.de","subject":"Re: git fsck messages - what to do about it?","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-09-16T10:47:43Z","receivedAt":"2005-09-16T10:47:43Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Wolfgang Denk <wd@denx.de> wrote:\n> -> git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*)\n> unreachable commit 08cf4121ad704faa5ae7c7ae7b3dca4476ef2770\n> unreachable tree 29a4c18afd958cc6cee938f0fe7fa59764418097\n> unreachable tree 3b722a7278e02b272ddc8aefbc7be22703d8a94f\n> unreachable tree 4ebc50d240d99b4236952d13d5044691f9078e3c\n> unreachable tree 63af5944e130b449338cc907ee77c51f4a69e339\n> unreachable tree 79c9a6bb02a80df15c7d829bdac0901f88c5e301\n> unreachable blob 85dcf4b5c4c0f6833cd63fa1d0fd29ef250162af\n> unreachable commit c1b779fbce762c970e3ace4332bb6ddc0de65e61\n> unreachable blob d70d1d44f12db7b2a3976c2a5313c90568a62c25\n> unreachable commit e1bcd2a5d53bceef2679737474487e32d87e7f2c\n>\n> I have to admit that I don't know what to do next...\n>\n> a) I understand that these  messages  are  indications  of  problems,\n>    right? What can I do to clean this up?\n>\n> b) Is there any way to find out what I did wrong in the first place?\n\nDid you use StGIT on your tree? StGIT can leave unreachable\nobjects. Otherwise, git-prune should remove them.\n\nNote that if you use StGIT, git-prune will also remove the commit\nobjects for the patches which are not pushed onto the stack. I will\nadd a 'stg prune' commands which takes care of these.\n\n-- \nCatalin\n"},{"id":"8671","messageId":"20050916110144.GB25169@pasky.or.cz","threadId":"1824","inReplyTo":"20050916101138.99906352682@atlas.denx.de","subject":"Re: git fsck messages - what to do about it?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-16T11:01:44Z","receivedAt":"2005-09-16T11:01:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Sep 16, 2005 at 12:11:38PM CEST, I got a letter\nwhere Wolfgang Denk <wd@denx.de> told me that...\n> When running git fsck I get some messages:\n> \n> -> git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*)\n> unreachable commit 08cf4121ad704faa5ae7c7ae7b3dca4476ef2770\n> unreachable tree 29a4c18afd958cc6cee938f0fe7fa59764418097\n> unreachable tree 3b722a7278e02b272ddc8aefbc7be22703d8a94f\n> unreachable tree 4ebc50d240d99b4236952d13d5044691f9078e3c\n> unreachable tree 63af5944e130b449338cc907ee77c51f4a69e339\n> unreachable tree 79c9a6bb02a80df15c7d829bdac0901f88c5e301\n> unreachable blob 85dcf4b5c4c0f6833cd63fa1d0fd29ef250162af\n> unreachable commit c1b779fbce762c970e3ace4332bb6ddc0de65e61\n> unreachable blob d70d1d44f12db7b2a3976c2a5313c90568a62c25\n> unreachable commit e1bcd2a5d53bceef2679737474487e32d87e7f2c\n> \n> I have to admit that I don't know what to do next...\n> \n> a) I understand that these  messages  are  indications  of  problems,\n>    right? What can I do to clean this up?\n> \n> b) Is there any way to find out what I did wrong in the first place?\n\nIn case you were using Cogito, cg-admin-uncommit will leave unreachable\nobjects in the database - it's safe to prune them (unless you'll decide\nlater that you after all wanted the uncommitted stuff, of course).\n\nBut note that IT IS NOT SAFE to prune repositories cloned with -l or\n_being_ cloned with -l. Perhaps one solution to this would be having\n.git/objects/info/repousers/ or something, which would contain symlinks\nback to all the repositories using the given objects database. Opinions?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8672","messageId":"20050916110310.90115352B7B@atlas.denx.de","threadId":"1824","inReplyTo":"tnx3bo59tm8.fsf@arm.com","subject":"Re: git fsck messages - what to do about it?","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-09-16T11:03:10Z","receivedAt":"2005-09-16T11:03:10Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <tnx3bo59tm8.fsf@arm.com> you wrote:\n>\n> > -> git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*)\n> > unreachable commit 08cf4121ad704faa5ae7c7ae7b3dca4476ef2770\n> > unreachable tree 29a4c18afd958cc6cee938f0fe7fa59764418097\n> > unreachable tree 3b722a7278e02b272ddc8aefbc7be22703d8a94f\n> > unreachable tree 4ebc50d240d99b4236952d13d5044691f9078e3c\n> > unreachable tree 63af5944e130b449338cc907ee77c51f4a69e339\n> > unreachable tree 79c9a6bb02a80df15c7d829bdac0901f88c5e301\n> > unreachable blob 85dcf4b5c4c0f6833cd63fa1d0fd29ef250162af\n> > unreachable commit c1b779fbce762c970e3ace4332bb6ddc0de65e61\n> > unreachable blob d70d1d44f12db7b2a3976c2a5313c90568a62c25\n> > unreachable commit e1bcd2a5d53bceef2679737474487e32d87e7f2c\n> >\n> > I have to admit that I don't know what to do next...\n> >\n> > a) I understand that these  messages  are  indications  of  problems,\n> >    right? What can I do to clean this up?\n> >\n> > b) Is there any way to find out what I did wrong in the first place?\n> \n> Did you use StGIT on your tree? StGIT can leave unreachable\n\nNo, I did not. I *think* these unreachable commits resulted from \"git\nresolve\"s  which  resulted  in  merge  conflicts,  which  I  resolved\nmanually. After this, I ran \"git commit\" manually, but probably I did\nsomething wrong. I just don't understand what this might have been...\n\n> objects. Otherwise, git-prune should remove them.\n\nUmmm.... I hesitate to  do  this  before  understanding  where  these\nmessages come from and what sort of data is affected.\n\n> Note that if you use StGIT, git-prune will also remove the commit\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering:  Embedded and Realtime Systems,  Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\nRemember that Beethoven wrote his first symphony in C ...\n"},{"id":"8689","messageId":"7vll1xndxi.fsf@assigned-by-dhcp.cox.net","threadId":"1824","inReplyTo":"20050916110310.90115352B7B@atlas.denx.de","subject":"Re: git fsck messages - what to do about it?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-16T17:02:49Z","receivedAt":"2005-09-16T17:02:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wolfgang Denk <wd@denx.de> writes:\n\n> Ummm.... I hesitate to  do  this  before  understanding  where  these\n> messages come from and what sort of data is affected.\n\nDoes git-fsck-cache without --unreachable report dangling\ncommits?  If so I would do something like this (this is my\n'git-lost-found' script):\n\n        #!/bin/sh\n\n        . git-sh-setup-script || die \"Not a git archive.\"\n\n        laf=\"$GIT_DIR/refs/lost-found\"\n        mkdir -p \"$laf\" || exit\n\n        git fsck-cache |\n        while read dangling type sha1\n        do\n                case \"$dangling\" in\n                dangling)\n                        echo \"$sha1\" >\"$laf/$sha1\"\n                        case \"$type\" in\n                        commit)\n                                git-show-branch \"$sha1\" ;;\n                        esac\n                        ;;\n                esac\n        done\n\nand run 'gitk --all' to see what these dangling commits are, and\nwhere in your commit ancestry mesh they fit in.  \n\nAfter you understand what they are, do not forget to \"rm -f\n$GIT_DIR/refs/lost-found/*\"; you made them reachable just to\nmake inspecting them easier, but you probably do not want them.\n\nI can sort of understand dangling blobs can come from manually\nresolved merges, but I do not think that would create dangling\ncommits.\n\nHave you rewound and rebased your history?  'git reset --hard'\nobviously throws the tip of the current branch away and 'git\nrebase' does it in order to recreate an alternate history.\nIf that is the case, and if you are satisfied with the history\nyour repository currently have, then obviously these can be\nsafely pruned.\n\nAnother possibility is what Pasky suggested -- do you have a\nsymlink .git/objects in another repository that points at the\n.git/objects directory of this repository?  These dangling\nthings may be objects the other repository needs.  If that is\nthe case you obviously cannot prune them -- you would corrupt\nthe other repository.\n"},{"id":"8699","messageId":"Pine.LNX.4.58.0509161114540.26803@g5.osdl.org","threadId":"1824","inReplyTo":"20050916101138.99906352682@atlas.denx.de","subject":"Re: git fsck messages - what to do about it?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-16T18:34:55Z","receivedAt":"2005-09-16T18:34:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 16 Sep 2005, Wolfgang Denk wrote:\n>\n> When running git fsck I get some messages:\n> \n> -> git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*)\n\nBtw, you shouldn't need to list the heads explicitly any more: if you \ndon't give any heads, git-fsck-cache by default will pick up all of them. \nIn fact, it will generally do a better job of it that you did, since it \nwill look at _all_ the refs in .git/refs/.\n\nThe above is very old-fashioned ;)\n\n> unreachable commit 08cf4121ad704faa5ae7c7ae7b3dca4476ef2770\n> unreachable tree 29a4c18afd958cc6cee938f0fe7fa59764418097\n> unreachable tree 3b722a7278e02b272ddc8aefbc7be22703d8a94f\n> unreachable tree 4ebc50d240d99b4236952d13d5044691f9078e3c\n> unreachable tree 63af5944e130b449338cc907ee77c51f4a69e339\n> unreachable tree 79c9a6bb02a80df15c7d829bdac0901f88c5e301\n> unreachable blob 85dcf4b5c4c0f6833cd63fa1d0fd29ef250162af\n> unreachable commit c1b779fbce762c970e3ace4332bb6ddc0de65e61\n> unreachable blob d70d1d44f12db7b2a3976c2a5313c90568a62c25\n> unreachable commit e1bcd2a5d53bceef2679737474487e32d87e7f2c\n> \n> I have to admit that I don't know what to do next...\n> \n> a) I understand that these  messages  are  indications  of  problems,\n>    right? What can I do to clean this up?\n\nFirst off, not necessarily. Especially if you have mixed rsync and the \n\"native git pack\" transports, you may have packs that refer to unpacked \nobjects, and then since git-fsck-cache by default doesn't look into packs \n(it assumes that they are fine and self-sufficient), you can get this \nerror.\n\nThe same is true if you have \"alternates\" directories: git-fsck-cache \nwon't do the reachability in the other directories by default.\n\nIf you add the \"--full\" flag, git-fsck-cache will also look at all those \nthings.\n\nNow, I assume that this isn't the case, and what you have is actually real \nunreachable objects. And that's perfectly normal too: it will happen if \nyou ever \"drop\" a commit (undo) by resetting a branch to its parent. For \nexample, if I notice I've made a mistake after a commit, I just do\n\n\tgit reset HEAD^\n\nwhich effectively undoes the commit. I can then fix things up and \nre-commit. And this is all _normal_.\n\nAnd what it results in is that the commit objects that I undid are\nobviously not reachable from anything else. git-fsck-cache will say that\nthey are unreachable, and \"git prune\" will get rid of them.\n\nThe same thing happens if you do \"git-update-cache\" on a file, but instead \nof committing that blob object, you realize that you need to edit it a bit \nmore, and do _another_ git-update-cache and commit only the final blob. \nThe first blob will be unreachable - nothing ends up pointing to it.\n\nSo an unreachable object is not necessarily an error at all. Git - very \nmuch on purpose - will leave the stale objects around, because it's too \nexpensive to try to be exact, so it's much better to just let them be, and \ndo an occasional \"cleanup\" with \"git prune\".\n\nThere are other reasons to have \"unreachable\" objects, even more benign. \n\nAny time you use \"rsync\" as the fetch protocol, you'll get _all_ the \nobjects from the other end. Regardless of whether you actually fetch all \nthe _refs_ from the other end. In particular, if the other end has \nmultiple branches, and you only pull _one_ of them, you'll still get the \nobjects for all the others. And git-fsck-cache will correctly say that \nthose objects are unreachable.\n\n(And _yet_ another reason for unreachable objects: you share the object \ndirectory with some other project - those objects will be unreachable from \n_your_ project, but maybe they're reachable from another one?)\n\n> b) Is there any way to find out what I did wrong in the first place?\n\nWell, it probably isn't even an error, but there are nice tools to check \nit out. For example, you can just list the commits it lists to gitk, and \nyou'll get a nice graphical view of where they are in the tree. That \nprobably makes you go \"Duh, yes, I did a 'git reset' to undo those\".\n\nOr maybe you recognize that the commit was clearly part of a chain that\nyou hadn't even committed, but came from another tree that you had \nrsync'ed with.\n\nAnd if that is the case, just ignore them. Or do \"git prune\" to keep your \ntree nice and clean, and to make \"git-fsck-cache --unreachable\" happy.\n\n\t\tLinus\n"},{"id":"8701","messageId":"Pine.LNX.4.58.0509161140141.26803@g5.osdl.org","threadId":"1824","inReplyTo":"Pine.LNX.4.58.0509161114540.26803@g5.osdl.org","subject":"Re: git fsck messages - what to do about it?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-16T18:50:06Z","receivedAt":"2005-09-16T18:50:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 16 Sep 2005, Linus Torvalds wrote:\n> \n> > b) Is there any way to find out what I did wrong in the first place?\n> \n> Well, it probably isn't even an error, but there are nice tools to check \n> it out. For example, you can just list the commits it lists to gitk, and \n> you'll get a nice graphical view of where they are in the tree. That \n> probably makes you go \"Duh, yes, I did a 'git reset' to undo those\".\n\nDoing exactly that:\n\n\tgitk 08cf4121ad704faa5ae7c7ae7b3dca4476ef2770 \\\n\t\t8493c04f1b8c9da0c5dc83091cabbcd0b98954ed \\\n\t\te1bcd2a5d53bceef2679737474487e32d87e7f2c \\\n\t\tc1b779fbce762c970e3ace4332bb6ddc0de65e61\n\nsays that three of the commits were the same one, redone:\n\n\tAdded support for mtddevnum and mtddevname variables.\n\nin one form or another (quick look at the diffs says that one was \napparently re-done because you forgot the changelog entry, I didn't look \nany closer).\n\nSo I suspect that's you just undoing a commit, and redoing it. I assume\nthat somewhere in the _reachable_ tree is one final commit that actually\ndid that, but I didn't bother to search for it (but that's easy too if you\nwant to:just go \"gitk --all\" and then search for that \"Added support for\nmtddevnum\"...)\n\nThe fourth commit is 8493c\n\n\tRebased: Rewrite of NAND code based on what is in 2.6.12 Linux kernel\n\nand considering that you seem to have other undo's in the tree, I'll just\nassume this is one more, but you would know.\n\n\t\tLinus\n"},{"id":"8808","messageId":"Pine.LNX.4.58.0509181435190.9106@g5.osdl.org","threadId":"1824","inReplyTo":"Pine.LNX.4.58.0509161114540.26803@g5.osdl.org","subject":"Re: git fsck messages - what to do about it?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-18T21:43:33Z","receivedAt":"2005-09-18T21:43:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 16 Sep 2005, Linus Torvalds wrote:\n>\n> > b) Is there any way to find out what I did wrong in the first place?\n> \n> Well, it probably isn't even an error, but there are nice tools to check \n> it out. For example, you can just list the commits it lists to gitk, and \n> you'll get a nice graphical view of where they are in the tree. That \n> probably makes you go \"Duh, yes, I did a 'git reset' to undo those\".\n\nOh, btw, one final note on this problem.\n\nThe \"--unreachable\" flag is meant to show a list of all objects that \naren't reachable from the refs (either the explicit ones, or the ones \ngit-fsck-objects finds on its own). That's very useful for when you \nactually want to remove them, ie \"git prune\" uses that flag.\n\nHowever, it's often not very interesting to see the full list of \nunreachable objects, because you are probably _not_ interested in the \ntrees that are reachable from the unreachable commit - you're really \ninterested in the \"tips of unreachability\".\n\nAnd that's what git-fsck-object actually reports _without_ any flags, as \n\"dangling\" objects. \n\nSo let's say that you have one commit that you've undone.\n\nIf you don't give any flags at all, git-fsck-objects will report\n\n\tdangling commit ...\n\nbut if you use \"--unreachable\" then you'll get the full list of objects, \nso you'll get\n\n\tunreachable tree ...\n\tunreachable blob ...\n\tunreachable commit ...\n\tunreachable blob ...\n\nwhich is usually _not_ what you want.\n\nSimilarly, let's say that you undid a series of three commits. There is \nonly one \"dangling\" commit (the \"tip\" of the series), but there are three \nunreachable commits (and any number of unreachable trees/blobs associated \nwith those commits). Again, what a human tends to be interested in is the \n\"dangling tip\", not the whole collection of unreachable objects that can \nbe reached through that tip.\n\nSo using \"--unreachable\" gives much more raw data, but it usually tends to\nhide the real _information_, and the end result is thus much harder to\nunderstand.\n\n\t\t\tLinus\n"},{"id":"8811","messageId":"7vfys210tm.fsf@assigned-by-dhcp.cox.net","threadId":"1824","inReplyTo":"Pine.LNX.4.58.0509181435190.9106@g5.osdl.org","subject":"Re: git fsck messages - what to do about it?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T22:13:41Z","receivedAt":"2005-09-18T22:13:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> So using \"--unreachable\" gives much more raw data, but it usually tends to\n> hide the real _information_, and the end result is thus much harder to\n> understand.\n\nYup.  That's exactly why the 'git-lost-found' sample script\ngiven in <7vll1xndxi.fsf@assigned-by-dhcp.cox.net> runs\ngit-fsck-objects output without --unreachable.\n"}]}