{"thread":{"id":"7703","subject":"Initial push of a fully packed repo - why repack?","startedAt":"2007-04-17T01:12:46Z","lastAt":"2007-04-17T02:49:10Z","messageCount":4,"participants":["Martin Langhoff","Nicolas Pitre"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39582","messageId":"46a038f90704161812r143b6d27scbcc401ee77c4597@mail.gmail.com","threadId":"7703","inReplyTo":null,"subject":"Initial push of a fully packed repo - why repack?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-17T01:12:46Z","receivedAt":"2007-04-17T01:12:46Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Pushing to a new empty repo, git spends a lot of time repacking, even\nif we have just run git-repack. The process looks like\n\n - use parsecvs to import a large CVS repo\n - git-repack -a -d (packs to ~550MB, taking ~1hr)\n - git-push --all git+ssh://host/newlycreatedrepo.git\n\nDoes it make sense to detect and optimise for this case?\n\ncheers,\n\n\nmartin\n"},{"id":"39585","messageId":"alpine.LFD.0.98.0704162215520.4504@xanadu.home","threadId":"7703","inReplyTo":"46a038f90704161812r143b6d27scbcc401ee77c4597@mail.gmail.com","subject":"Re: Initial push of a fully packed repo - why repack?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-17T02:21:10Z","receivedAt":"2007-04-17T02:21:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 17 Apr 2007, Martin Langhoff wrote:\n\n> Pushing to a new empty repo, git spends a lot of time repacking, even\n> if we have just run git-repack. The process looks like\n> \n> - use parsecvs to import a large CVS repo\n> - git-repack -a -d (packs to ~550MB, taking ~1hr)\n> - git-push --all git+ssh://host/newlycreatedrepo.git\n> \n> Does it make sense to detect and optimise for this case?\n\nMaybe...  Although the second repack during the push should be much much \nfaster than the first one.\n\n\nNicolas\n"},{"id":"39588","messageId":"46a038f90704161928q4597c97ajd33106f119516328@mail.gmail.com","threadId":"7703","inReplyTo":"alpine.LFD.0.98.0704162215520.4504@xanadu.home","subject":"Re: Initial push of a fully packed repo - why repack?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-17T02:28:06Z","receivedAt":"2007-04-17T02:28:06Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/17/07, Nicolas Pitre <nico@cam.org> wrote:\n> On Tue, 17 Apr 2007, Martin Langhoff wrote:\n> > Does it make sense to detect and optimise for this case?\n> Maybe...  Although the second repack during the push should be much much\n> faster than the first one.\n\nIt is - but it still burns through perhaps 1 minute of CPU and IO\nrewriting the exact same pack as you can see:\n\nGenerating pack...\nDone counting 290123 objects.\nDeltifying 290123 objects.\n 100% (290123/290123) done\nWriting 290123 objects.\n 100% (290123/290123) done\nTotal 290123 (delta 234293), reused 290123 (delta 234293)\n\ncheers,\n\n\nmartin\n"},{"id":"39590","messageId":"alpine.LFD.0.98.0704162235350.4504@xanadu.home","threadId":"7703","inReplyTo":"46a038f90704161928q4597c97ajd33106f119516328@mail.gmail.com","subject":"Re: Initial push of a fully packed repo - why repack?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-17T02:49:10Z","receivedAt":"2007-04-17T02:49:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 17 Apr 2007, Martin Langhoff wrote:\n\n> On 4/17/07, Nicolas Pitre <nico@cam.org> wrote:\n> > On Tue, 17 Apr 2007, Martin Langhoff wrote:\n> > > Does it make sense to detect and optimise for this case?\n> > Maybe...  Although the second repack during the push should be much much\n> > faster than the first one.\n> \n> It is - but it still burns through perhaps 1 minute of CPU and IO\n> rewriting the exact same pack as you can see:\n\nSure.  On the IO you can't save.  You'll have to copy the packanyway and \nwith all objects being \"reused\" the pack-objects code is basically not \ndoing much more than a straight cp would do.\n\nWhat is costly is figuring out if the single pack you have actually\ncontains all the objects you wish to push, and _only_ the objects you \nwish to push.  That is the real cost.  By the time all those objects are \nlisted and accounted then repacking is basically copying the data \nover with almost no CPU usage.  In other words, the cost to determine if \nit is OK to simply send the pack you already have and actually \nsending it would be sensibly the same.\n\n\nNicolas\n"}]}