{"thread":{"id":"6529","subject":"Question about fsck-objects output","startedAt":"2007-01-25T18:22:45Z","lastAt":"2007-01-25T20:08:16Z","messageCount":4,"participants":["Larry Streepy","Shawn O. Pearce","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32633","messageId":"45B8F575.5050106@lightspeed.com","threadId":"6529","inReplyTo":null,"subject":"Question about fsck-objects output","fromName":"Larry Streepy","fromEmail":"larry@lightspeed.com","sentAt":"2007-01-25T18:22:45Z","receivedAt":"2007-01-25T18:22:45Z","isPatch":false,"sender":{"key":"larry@lightspeed.com","avatar":null},"body":"Sorry to ask such a basic question, but I can't quite decipher the output \nof fsck-objects.  When I run it, I get this:\n\n  git fsck-objects\ndangling commit 2213f6d4dd39ca8baebd0427723723e63208521b\ndangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f\ndangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761\n\n\nEven after a \"repack -a -d\" they still exist.  The man page has a short \nexplanation, but, at least for me, it wasn't fully enlightening. :-)\n\nThe man page says that dangling commits could be \"root\" commits, but since \nmy repo started as a clone of another repo, I don't see how I could have \nany root commits.  Also, the page doesn't really describe what a dangling \nblob is.\n\nSo, can someone explain what these artifacts are and if they are a problem \nthat I should be worried about?\n\nThanks,\nLarry.\n"},{"id":"32634","messageId":"20070125193112.GE13089@spearce.org","threadId":"6529","inReplyTo":"45B8F575.5050106@lightspeed.com","subject":"Re: Question about fsck-objects output","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-25T19:31:12Z","receivedAt":"2007-01-25T19:31:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Larry Streepy <larry@lightspeed.com> wrote:\n> Sorry to ask such a basic question, but I can't quite decipher the output \n> of fsck-objects.  When I run it, I get this:\n> \n>  git fsck-objects\n> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b\n> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f\n> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761\n> \n> \n> Even after a \"repack -a -d\" they still exist.  The man page has a short \n> explanation, but, at least for me, it wasn't fully enlightening. :-)\n> \n> The man page says that dangling commits could be \"root\" commits, but since \n> my repo started as a clone of another repo, I don't see how I could have \n> any root commits.  Also, the page doesn't really describe what a dangling \n> blob is.\n> \n> So, can someone explain what these artifacts are and if they are a problem \n> that I should be worried about?\n\nThese were probably created by amending a commit (`git commit --amend`).\n\nDangling commits simply mean no existing branch points at them,\neither directly by a ref/tag or indirectly by the commit being\nmerged into them.  They aren't part of any interesting history.\nThey could also be caused by deleting a branch before it was fully\nmerged into another branch.  The commits and history are still\nthere, they just lack a name.\n\nDangling blobs mean the same thing; no existing branch uses\nthem in their revisions.\n\nWhat most likely happened here was you committed a change, realized\nit was slightly wrong, modified one file, then used `git commit\n--amend -a` to update the commit with the correction.  Later you\nprobably did the same thing, but only to correct the commit message.\nThe first instance caused the blob and commit to dangle, the\nsecond caused another commit to dangle.\n\nYou can use `git show id` (where id is the commit id above) to see\nwhat the commit actually is.\n\nYou can use `git prune` to have these objects deleted.  For safety\nreasons `repack -a -d` won't touch them.  But they don't take up\na lot of disk space (usually) so pruning isn't something to be\ntoo concerned about.\n\n-- \nShawn.\n"},{"id":"32635","messageId":"Pine.LNX.4.64.0701251144290.25027@woody.linux-foundation.org","threadId":"6529","inReplyTo":"45B8F575.5050106@lightspeed.com","subject":"Re: Question about fsck-objects output","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-25T20:01:06Z","receivedAt":"2007-01-25T20:01:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Maybe this should be a FAQ answer in some git documentation? Feel free \n  to edit up this email and use it as a base.. ]\n\nOn Thu, 25 Jan 2007, Larry Streepy wrote:\n\n> Sorry to ask such a basic question, but I can't quite decipher the output of\n> fsck-objects.  When I run it, I get this:\n> \n>  git fsck-objects\n> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b\n> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f\n> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761\n> \n> \n> Even after a \"repack -a -d\" they still exist.  The man page has a short\n> explanation, but, at least for me, it wasn't fully enlightening. :-)\n> \n> The man page says that dangling commits could be \"root\" commits, but since my\n> repo started as a clone of another repo, I don't see how I could have any root\n> commits.  Also, the page doesn't really describe what a dangling blob is.\n> \n> So, can someone explain what these artifacts are and if they are a problem\n> that I should be worried about?\n\nThe most common situation is that you've rebased a branch (or you have \npulled from somebody else who rebased a branch, like the \"pu\" branch in \nthe git.git archive itself).\n\nWhat happens is that the old head of the original branch still exists, as \ndoes obviously everything it pointed to. The branch pointer itself just \ndoesn't, since you replaced it with another one.\n\nHowever, there are certainly other situations too that cause dangling \nobjects. For example, the \"dangling blob\" situation you have tends to be \nbecause you did a \"git add\" of a file, but then, before you actually \ncommitted it and made it part of the bigger picture, you changed something \nelse in that file and committed that *updated* thing - the old state that \nyou added originally ends up not being pointed to by any commit/tree, so \nit's now a dangling blob object.\n\nSimilarly, when the \"recursive\" merge strategy runs, and finds that there \nare criss-cross merges and thus more than one merge base (which is fairly \nunusual, but it does happen), it will generate one temporary midway tree \n(or possibly even more, if you had lots of criss-crossing merges and \nmore than two merge bases) as a temporary internal merge base, and again, \nthose are real objects, but the end result will not end up pointing to \nthem, so they end up \"dangling\" in your repository.\n\nGenerally, dangling objects aren't anything to worry about. They can even \nbe very useful: if you screw something up, the dangling objects can be how \nyou recover your old tree (say, you did a rebase, and realized that you \nreally didn't want to - you can look at what dangling objects you have, \nand decide to reset your head to some old dangling state).\n\nFor commits, the most useful thing to do with dangling objects tends to be \nto do a simple\n\n\tgitk <dangling-commit-sha-goes-here> --not --all\n\nwhich means exactly what it sounds like: it says that you want to see the \ncommit history that is described by the dangling commit(s), but you do NOT \nwant to see the history that is described by all your branches and tags \n(which are the things you normally reach). That basically shows you in a \nnice way what the danglign commit was (and notice that it might not be \njust one commit: we only report the \"tip of the line\" as being dangling, \nbut there might be a whole deep and complex commit history that has gotten \ndropped - rebasing will do that).\n\nFor blobs and trees, you can't do the same, but you can examine them. You \ncan just do\n\n\tgit show <dangling-blob/tree-sha-goes-here>\n\nto show what the contents of the blob were (or, for a tree, basically what \nthe \"ls\" for that directory was), and that may give you some idea of what \nthe operation was that left that dangling object.\n\nUsually, dangling blobs and trees aren't very interesting. They're almost \nalways the result of either being a half-way mergebase (the blob will \noften even have the conflict markers from a merge in it, if you have had \nconflicting merges that you fixed up by hand), or simply because you \ninterrupted a \"git fetch\" with ^C or something like that, leaving _some_ \nof the new objects in the object database, but just dangling and useless.\n\nAnyway, once you are sure that you're not interested in any dangling \nstate, you can just prune all unreachable objects:\n\n\tgit prune\n\nand they'll be gone. But you should only run \"git prune\" on a quiescent \nrepository - it's kind of like doing a filesystem fsck recovery: you don't \nwant to do that while the filesystem is mounted.\n\n(The same is true of \"git-fsck-objects\" itself, btw - but since \ngit-fsck-objects never actually *changes* the repository, it just reports \non what it found, git-fsck-objects itself is never \"dangerous\" to run. \nRunning it while somebody is actually changing the repository can cause \nconfusing and scary messages, but it won't actually do anything bad. In \ncontrast, running \"git prune\" while somebody is actively changing the \nrepository is a *BAD* idea).\n\n\t\t\tLinus\n"},{"id":"32636","messageId":"45B90E30.2020105@lightspeed.com","threadId":"6529","inReplyTo":"Pine.LNX.4.64.0701251144290.25027@woody.linux-foundation.org","subject":"Re: Question about fsck-objects output","fromName":"Larry Streepy","fromEmail":"larry@lightspeed.com","sentAt":"2007-01-25T20:08:16Z","receivedAt":"2007-01-25T20:08:16Z","isPatch":false,"sender":{"key":"larry@lightspeed.com","avatar":null},"body":"Excellent, I have done a rebase, so that could certainly be it.  I'll \ntake a look at the contents using the suggestions you provided.\n\nThanks for the enlightenment. :-)\n\nLarry.\n\nLinus Torvalds wrote:\n> [ Maybe this should be a FAQ answer in some git documentation? Feel free \n>   to edit up this email and use it as a base.. ]\n>\n> On Thu, 25 Jan 2007, Larry Streepy wrote:\n>\n>   \n>> Sorry to ask such a basic question, but I can't quite decipher the output of\n>> fsck-objects.  When I run it, I get this:\n>>\n>>  git fsck-objects\n>> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b\n>> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f\n>> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761\n>>\n>>\n>> Even after a \"repack -a -d\" they still exist.  The man page has a short\n>> explanation, but, at least for me, it wasn't fully enlightening. :-)\n>>\n>> The man page says that dangling commits could be \"root\" commits, but since my\n>> repo started as a clone of another repo, I don't see how I could have any root\n>> commits.  Also, the page doesn't really describe what a dangling blob is.\n>>\n>> So, can someone explain what these artifacts are and if they are a problem\n>> that I should be worried about?\n>>     \n>\n> The most common situation is that you've rebased a branch (or you have \n> pulled from somebody else who rebased a branch, like the \"pu\" branch in \n> the git.git archive itself).\n>\n> What happens is that the old head of the original branch still exists, as \n> does obviously everything it pointed to. The branch pointer itself just \n> doesn't, since you replaced it with another one.\n>\n> However, there are certainly other situations too that cause dangling \n> objects. For example, the \"dangling blob\" situation you have tends to be \n> because you did a \"git add\" of a file, but then, before you actually \n> committed it and made it part of the bigger picture, you changed something \n> else in that file and committed that *updated* thing - the old state that \n> you added originally ends up not being pointed to by any commit/tree, so \n> it's now a dangling blob object.\n>\n> Similarly, when the \"recursive\" merge strategy runs, and finds that there \n> are criss-cross merges and thus more than one merge base (which is fairly \n> unusual, but it does happen), it will generate one temporary midway tree \n> (or possibly even more, if you had lots of criss-crossing merges and \n> more than two merge bases) as a temporary internal merge base, and again, \n> those are real objects, but the end result will not end up pointing to \n> them, so they end up \"dangling\" in your repository.\n>\n> Generally, dangling objects aren't anything to worry about. They can even \n> be very useful: if you screw something up, the dangling objects can be how \n> you recover your old tree (say, you did a rebase, and realized that you \n> really didn't want to - you can look at what dangling objects you have, \n> and decide to reset your head to some old dangling state).\n>\n> For commits, the most useful thing to do with dangling objects tends to be \n> to do a simple\n>\n> \tgitk <dangling-commit-sha-goes-here> --not --all\n>\n> which means exactly what it sounds like: it says that you want to see the \n> commit history that is described by the dangling commit(s), but you do NOT \n> want to see the history that is described by all your branches and tags \n> (which are the things you normally reach). That basically shows you in a \n> nice way what the danglign commit was (and notice that it might not be \n> just one commit: we only report the \"tip of the line\" as being dangling, \n> but there might be a whole deep and complex commit history that has gotten \n> dropped - rebasing will do that).\n>\n> For blobs and trees, you can't do the same, but you can examine them. You \n> can just do\n>\n> \tgit show <dangling-blob/tree-sha-goes-here>\n>\n> to show what the contents of the blob were (or, for a tree, basically what \n> the \"ls\" for that directory was), and that may give you some idea of what \n> the operation was that left that dangling object.\n>\n> Usually, dangling blobs and trees aren't very interesting. They're almost \n> always the result of either being a half-way mergebase (the blob will \n> often even have the conflict markers from a merge in it, if you have had \n> conflicting merges that you fixed up by hand), or simply because you \n> interrupted a \"git fetch\" with ^C or something like that, leaving _some_ \n> of the new objects in the object database, but just dangling and useless.\n>\n> Anyway, once you are sure that you're not interested in any dangling \n> state, you can just prune all unreachable objects:\n>\n> \tgit prune\n>\n> and they'll be gone. But you should only run \"git prune\" on a quiescent \n> repository - it's kind of like doing a filesystem fsck recovery: you don't \n> want to do that while the filesystem is mounted.\n>\n> (The same is true of \"git-fsck-objects\" itself, btw - but since \n> git-fsck-objects never actually *changes* the repository, it just reports \n> on what it found, git-fsck-objects itself is never \"dangerous\" to run. \n> Running it while somebody is actually changing the repository can cause \n> confusing and scary messages, but it won't actually do anything bad. In \n> contrast, running \"git prune\" while somebody is actively changing the \n> repository is a *BAD* idea).\n>\n> \t\t\tLinus\n>   \n\n\n\nbegin:vcard\nfn:Larry Streepy\nn:Streepy;Larry\norg:Lightspeed Logic\nadr;dom:Building 2, suite 130;;11612 Bee Caves Road;Austin;TX;78738\nemail;internet:larry@lightspeed.com\ntitle:Sr. Staff Software Engineer\ntel;work:408-616-3292\nx-mozilla-html:TRUE\nurl:http://ww.lightspeed.com\nversion:2.1\nend:vcard\n\n"}]}