{"thread":{"id":"5705","subject":"git packing leaves unpacked files","startedAt":"2006-09-26T18:04:56Z","lastAt":"2006-09-26T18:28:39Z","messageCount":3,"participants":["Andy Whitcroft","Jakub Narebski","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27688","messageId":"45196BC8.8060608@shadowen.org","threadId":"5705","inReplyTo":null,"subject":"git packing leaves unpacked files","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-09-26T18:04:56Z","receivedAt":"2006-09-26T18:04:56Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"I was just looking at my kernel repository and noticed that even after a\ngit repack -a -d I have some loose files.  A quick look at repack\ndoesn't seem to explain why some are either not packed or are kept unpacked.\n\nIs this something I should be expecting?\n\n-apw\n"},{"id":"27691","messageId":"efbqeb$guv$1@sea.gmane.org","threadId":"5705","inReplyTo":"45196BC8.8060608@shadowen.org","subject":"Re: git packing leaves unpacked files","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-26T18:10:25Z","receivedAt":"2006-09-26T18:10:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Whitcroft wrote:\n\n> I was just looking at my kernel repository and noticed that even after a\n> git repack -a -d I have some loose files.  A quick look at repack\n> doesn't seem to explain why some are either not packed or are kept unpacked.\n> \n> Is this something I should be expecting?\n\nTry git-fsck-objects. Perhaps those loose files are the ones which will\nbe pruned.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27693","messageId":"Pine.LNX.4.64.0609261116170.3952@g5.osdl.org","threadId":"5705","inReplyTo":"45196BC8.8060608@shadowen.org","subject":"Re: git packing leaves unpacked files","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-26T18:28:39Z","receivedAt":"2006-09-26T18:28:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Sep 2006, Andy Whitcroft wrote:\n>\n> I was just looking at my kernel repository and noticed that even after a\n> git repack -a -d I have some loose files.  A quick look at repack\n> doesn't seem to explain why some are either not packed or are kept unpacked.\n> \n> Is this something I should be expecting?\n\nDepending on what you're doing, yes.\n\nYou can often get a hint of what is going on by just running \n\"git-fsck-objects\" and seeing the \"dangling\" objects - objects that exist, \nbut are not reachable.\n\nThere are a few things that cause dangling objects quite normally:\n\n - If you use \"git update-index\" to update the index half-way, and then do \n   more work, and use \"git update-index\" again (or commit), then the \n   half-way work will visible be in the form of dangling blobs. You can \n   just do a \"git cat-file -p <blobname>\" and see it, and maybe you'll \n   recognize that it was something you were about to commit, but never \n   did, because you did further development.\n\n - if you ever rebase any branch in the project, or do \"git reset\" to set \n   it to some old point, or delete a branch, dangling commits are very \n   much to be expected.\n\n - Even if _you_ didn't rebase anything, if the project you track rebases \n   itself, you'll get dangling objects because you had commits that became \n   unreachable when they were replaced by new history.\n\n   My kernel tree doesn't do that, but some other ones occasionally do, \n   and git itself (in the \"pu\" branch) obviously does all the time.\n\n   This is often the most common reason, especially if you follow \n   Junio's git tree.\n\n   The most common sign of this is that there's a few dangling commits, \n   and when you use gitk to examine them, you see old valid commits that \n   just aren't reachable any more.\n\n - if you do any merges at all, and they've conflicted or they have had \n   more than one parent and the recursive merger has generated an \n   intermediate version of the tree, you'll have the merge process leave \n   the objects of those intermediate merges around as dangling left-overs \n   that aren't actually reachable from the end result of the merge.\n\n   The most common form of this is that you see a few pending \"blob\"s, and \n   when you do \"git cat-file -p <sha1> | less -S\" on the blob-file, you'll \n   generally find a conflict marker in it (ie the \"<<<<\" \"====\" \">>>>\" \n   things that a three-way merge leaves behind). You might also have a \n   whole dangling tree due to this.\n\n - if you use the rsync:// protocol, you'll often end up getting objects \n   that aren't reachable from the heads _you_ have, because you got the \n   whole object database from somebody else that had other heads (or, you \n   might get the dangling objects that they had due to any of the reasons \n   above).\n\n   The rsync:// protocol simply doesn't do any git-level reachability \n   analysis, so it just gets everything, regardless.\n\nHmm. Those are tha main reasons I can think of. There may be other cases, \nbut I think these are the main ones, and I think any other cases end up \nbeing just variations on the same kind of theme.\n\n\t\t\tLinus\n"}]}