{"thread":{"id":"5870","subject":"is git-unpack-objects now redundant for 'git-push' and friends?","startedAt":"2006-10-10T13:23:52Z","lastAt":"2006-10-10T17:44:39Z","messageCount":3,"participants":["Sam Vilain","Shawn Pearce","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28514","messageId":"452B9EE8.5020702@vilain.net","threadId":"5870","inReplyTo":null,"subject":"is git-unpack-objects now redundant for 'git-push' and friends?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-10-10T13:23:52Z","receivedAt":"2006-10-10T13:23:52Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"When pushing or pulling to/from a repository, why unpack the objects?\nWhy not just fsck and then throw the pack into $GIT_DIR/objects/pack?\n\nIf you're pushing the entire repository, for instance, currently you\nmight create 10,000's of files, which will just be thrown away later\nwhen you `git-repack -d'.\n\nI suspect that this was never changed, because there never used to be\nmore than one packfile allowed, correct?\n\nIf the server *does* send us duplicates of objects we already have for\nsome reason, well that's what `git-repack -a -d' is for.\n\nI'm just wondering if there are any good reasons to do this any more.\n\nSam.\n"},{"id":"28519","messageId":"20061010161405.GB16412@spearce.org","threadId":"5870","inReplyTo":"452B9EE8.5020702@vilain.net","subject":"Re: is git-unpack-objects now redundant for 'git-push' and friends?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-10T16:14:05Z","receivedAt":"2006-10-10T16:14:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sam Vilain <sam@vilain.net> wrote:\n> When pushing or pulling to/from a repository, why unpack the objects?\n> Why not just fsck and then throw the pack into $GIT_DIR/objects/pack?\n> \n> If you're pushing the entire repository, for instance, currently you\n> might create 10,000's of files, which will just be thrown away later\n> when you `git-repack -d'.\n> \n> I suspect that this was never changed, because there never used to be\n> more than one packfile allowed, correct?\n> \n> If the server *does* send us duplicates of objects we already have for\n> some reason, well that's what `git-repack -a -d' is for.\n> \n> I'm just wondering if there are any good reasons to do this any more.\n\nThere's still a few good reasons to unpack things, even though I\nhate sitting through 5000 objects unpacking on a Windows system,\nor a very slow NFS system (one NFS based system I work with unpacks\nsmall <1KiB objects at a rate of about 1 every 15 seconds).\n\n - We don't completely trust the remote peer.  If the remote sends\n   us an object we already have we want to use the bytes we have\n   and not the bytes they are sending.  That way even if the remote\n   were able to generate a hash collision and produce a replacement\n   byte sequence with the same hash, our known good byte sequence\n   is not affected.\n\n - Packs sent over the network can be thin packs.  A think pack\n   may not contain the object used as the delta base for a delta\n   within that pack.  This is done to save network bandwidth when\n   both sides already have the delta base for an object that is\n   being transferred.\n\n - Local packs cannot access delta base objects not in the same\n   pack.  This limitation simplifies the pack access code in a\n   lot of the system.  It also means that you can in a worst case\n   scenario obtain everything in that pack back when all you have\n   is the pack file itself.\n\nI'm sure there's more reasons than that, but those are the major\nones.\n\n-- \nShawn.\n"},{"id":"28526","messageId":"7v7iz82hh4.fsf@assigned-by-dhcp.cox.net","threadId":"5870","inReplyTo":"452B9EE8.5020702@vilain.net","subject":"Re: is git-unpack-objects now redundant for 'git-push' and friends?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-10T17:44:39Z","receivedAt":"2006-10-10T17:44:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain <sam@vilain.net> writes:\n\n> When pushing or pulling to/from a repository, why unpack the objects?\n> Why not just fsck and then throw the pack into $GIT_DIR/objects/pack?\n>...\n> I suspect that this was never changed, because there never used to be\n> more than one packfile allowed, correct?\n\nWe've supported more than one packs at the same time from the\nday we supported packs.\n\nPrimary reason that push never keeps the pack is that explosion\ninto loose objects hurts you only at the first round and later\npushes are supposed to be much smaller, so changing it to keep\nthe pack for the initial one has a very small value making it a\nvery low priority change.  Not keeping the pack on push makes it\npossible to always use --thin for pushing if we wanted to.\n\nOn the fetch side you could use --keep option when you know the\nfetch will be huge.\n"}]}