# Initial push of a fully packed repo - why repack? 4 messages from 2007-04-17 to 2007-04-17. Participants: Martin Langhoff, Nicolas Pitre. Thread: https://gitlist.dev/t/7703 ## Martin Langhoff, 2007-04-17 01:12 Subject: Initial push of a fully packed repo - why repack? Message-ID: <46a038f90704161812r143b6d27scbcc401ee77c4597@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90704161812r143b6d27scbcc401ee77c4597%40mail.gmail.com ``` Pushing to a new empty repo, git spends a lot of time repacking, even if we have just run git-repack. The process looks like - use parsecvs to import a large CVS repo - git-repack -a -d (packs to ~550MB, taking ~1hr) - git-push --all git+ssh://host/newlycreatedrepo.git Does it make sense to detect and optimise for this case? cheers, martin ``` ## Nicolas Pitre, 2007-04-17 02:21 Subject: Re: Initial push of a fully packed repo - why repack? Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0704162215520.4504%40xanadu.home In-Reply-To: <46a038f90704161812r143b6d27scbcc401ee77c4597@mail.gmail.com> ``` On Tue, 17 Apr 2007, Martin Langhoff wrote: > Pushing to a new empty repo, git spends a lot of time repacking, even > if we have just run git-repack. The process looks like > > - use parsecvs to import a large CVS repo > - git-repack -a -d (packs to ~550MB, taking ~1hr) > - git-push --all git+ssh://host/newlycreatedrepo.git > > Does it make sense to detect and optimise for this case? Maybe... Although the second repack during the push should be much much faster than the first one. Nicolas ``` ## Martin Langhoff, 2007-04-17 02:28 Subject: Re: Initial push of a fully packed repo - why repack? Message-ID: <46a038f90704161928q4597c97ajd33106f119516328@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90704161928q4597c97ajd33106f119516328%40mail.gmail.com In-Reply-To: ``` On 4/17/07, Nicolas Pitre wrote: > On Tue, 17 Apr 2007, Martin Langhoff wrote: > > Does it make sense to detect and optimise for this case? > Maybe... Although the second repack during the push should be much much > faster than the first one. It is - but it still burns through perhaps 1 minute of CPU and IO rewriting the exact same pack as you can see: Generating pack... Done counting 290123 objects. Deltifying 290123 objects. 100% (290123/290123) done Writing 290123 objects. 100% (290123/290123) done Total 290123 (delta 234293), reused 290123 (delta 234293) cheers, martin ``` ## Nicolas Pitre, 2007-04-17 02:49 Subject: Re: Initial push of a fully packed repo - why repack? Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0704162235350.4504%40xanadu.home In-Reply-To: <46a038f90704161928q4597c97ajd33106f119516328@mail.gmail.com> ``` On Tue, 17 Apr 2007, Martin Langhoff wrote: > On 4/17/07, Nicolas Pitre wrote: > > On Tue, 17 Apr 2007, Martin Langhoff wrote: > > > Does it make sense to detect and optimise for this case? > > Maybe... Although the second repack during the push should be much much > > faster than the first one. > > It is - but it still burns through perhaps 1 minute of CPU and IO > rewriting the exact same pack as you can see: Sure. On the IO you can't save. You'll have to copy the packanyway and with all objects being "reused" the pack-objects code is basically not doing much more than a straight cp would do. What is costly is figuring out if the single pack you have actually contains all the objects you wish to push, and _only_ the objects you wish to push. That is the real cost. By the time all those objects are listed and accounted then repacking is basically copying the data over with almost no CPU usage. In other words, the cost to determine if it is OK to simply send the pack you already have and actually sending it would be sensibly the same. Nicolas ```