{"thread":{"id":"14927","subject":"git gc does not discard objects found in alternate unless the alternate storage is packed","startedAt":"2008-08-10T21:07:29Z","lastAt":"2008-08-11T14:33:08Z","messageCount":4,"participants":["Sergio","Shawn O. Pearce","sergio"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"86719","messageId":"loom.20080810T210546-549@post.gmane.org","threadId":"14927","inReplyTo":null,"subject":"git gc does not discard objects found in alternate unless the alternate storage is packed","fromName":"Sergio","fromEmail":"sergio.callegari@gmail.com","sentAt":"2008-08-10T21:07:29Z","receivedAt":"2008-08-10T21:07:29Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Version 1.5.6.5\n\nLooks weird\nIs it the intended behaviour?\n\nSergio\n"},{"id":"86743","messageId":"20080811025438.GB27195@spearce.org","threadId":"14927","inReplyTo":"loom.20080810T210546-549@post.gmane.org","subject":"Re: git gc does not discard objects found in alternate unless the alternate storage is packed","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-11T02:54:38Z","receivedAt":"2008-08-11T02:54:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sergio wrote:\n> Version 1.5.6.5\n> \n> Looks weird\n> Is it the intended behaviour?\n\nThis is the current (intended) behavior. We have never pruned an\nobject from a repository unless the object is packed in the shared\nalternate repository. See git-prune-packed's man page. The prune\nlogic for loose objects only deletes objects which are in packs,\nand it doesn't care where that pack came from.\n\n-- \nShawn.\n"},{"id":"86759","messageId":"loom.20080811T101110-879@post.gmane.org","threadId":"14927","inReplyTo":"20080811025438.GB27195@spearce.org","subject":"Re: git gc does not discard objects found in alternate unless the alternate storage is packed","fromName":"sergio","fromEmail":"sergio.callegari@gmail.com","sentAt":"2008-08-11T10:16:28Z","receivedAt":"2008-08-11T10:16:28Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Shawn O. Pearce spearce.org> writes:\n\n> \n> Sergio gmail.com> wrote:\n> > Version 1.5.6.5\n> > \n> > Looks weird\n> > Is it the intended behaviour?\n> \n> This is the current (intended) behavior. We have never pruned an\n> object from a repository unless the object is packed in the shared\n> alternate repository. See git-prune-packed's man page. The prune\n> logic for loose objects only deletes objects which are in packs,\n> and it doesn't care where that pack came from.\n> \n\nMany thanks for the explanation.\nTwo more questions:\n1) Is there a way to prune objects that are anyway available at the alternate\nwithout touching the alternate (to repack it)?\n2) Would there be any contraindication in doing so? (namely, is the current\nbehaviour of git gc a mere consequence of the prune-packed logic or a behaviour\npurposely introduced for safety?)\n\n\nSergio\n"},{"id":"86772","messageId":"20080811143308.GA26363@spearce.org","threadId":"14927","inReplyTo":"loom.20080811T101110-879@post.gmane.org","subject":"Re: git gc does not discard objects found in alternate unless the?alternate storage is packed","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-11T14:33:08Z","receivedAt":"2008-08-11T14:33:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"sergio wrote:\n> Shawn O. Pearce spearce.org> writes:\n> > Sergio gmail.com> wrote:\n> > >\n> > > Is it the intended behaviour?\n> > \n> > This is the current (intended) behavior. We have never pruned an\n> > object from a repository unless the object is packed in the shared\n> > alternate repository. See git-prune-packed's man page. The prune\n> > logic for loose objects only deletes objects which are in packs,\n> > and it doesn't care where that pack came from.\n> \n> Many thanks for the explanation.\n> Two more questions:\n> 1) Is there a way to prune objects that are anyway available at the alternate\n> without touching the alternate (to repack it)?\n\nNo, no such function exists today in Git. Why? Because nobody has\ncoded it. We needed git-prune-packed for local repository usage\nonce git-repack has finished its main work of running pack-objects\nto produce a new pack file. This extended nicely into also pruning\nloose objects which are also available from a shared database,\nas the code was actually identical.\n\n> 2) Would there be any contraindication in doing so? (namely, is the current\n> behaviour of git gc a mere consequence of the prune-packed logic or a behaviour\n> purposely introduced for safety?)\n\nWell, yes and no.\n\nThe first part of the answer is that yes, one could delete the\nobject from the clone if it is available loose in the alternate.\nThe object can still be read through the alternate, so there is no\ndata loss, and thus it really is just a matter of someone writing\nthe necessary code to implement this prune function.\n\nThe second part of the answer is that no, doing this deletion may\nmake it less safe to use the alternate as an alternate. The reason\nis that objects which are contained in pack files are likely to\nbe reachable in the alternate, and thus won't disappear during a\nlater git-prune invocation, as they are needed by that alternate.\n\nThis assumption is based upon the fact that an object only goes\ninto a pack file if it is reachable in that repository, as the\npacking code uses reachability to determine what to pack.\n\nRelying upon a loose object may cause breakage later on if the\nalternate doesn't actually need that object and prunes it away,\nand the clone doesn't have it either.\n\nHowever, this pack based assumption can fail anyway if the\nalternate repository rewinds a branch and repacks. The object you\nwere relying on in the alternate may now be ejected into a loose\nobject, or discarded altogether, and the clone will (eventually)\nbreak anyway when the object(s) it needs goes missing.\n\nSo it is sort-of a safety measure, but its a crude one at best.\nAnd it only works about some X% of the time, where X is well\nunder 100. :-)\n\n-- \nShawn.\n"}]}