git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Initial push of a fully packed repo - why repack?

From
Nicolas Pitre <nico@cam.org>
Date
Apr 17, 2007, 02:21 UTC
Message-ID
<alpine.LFD.0.98.0704162215520.4504@xanadu.home>
In-Reply-To
<46a038f90704161812r143b6d27scbcc401ee77c4597@mail.gmail.com>
On Tue, 17 Apr 2007, Martin Langhoff wrote:
Show 8 quoted lines
> 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
Previous: Martin LanghoffNext: Martin Langhoff
Message 2 of 4 in “Initial push of a fully packed repo - why repack?”
  1. Martin LanghoffApr 17, 2007
  2. Nicolas PitreApr 17, 2007
  3. Martin LanghoffApr 17, 2007
  4. Nicolas PitreApr 17, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.