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

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

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Apr 17, 2007, 02:28 UTC
Message-ID
<46a038f90704161928q4597c97ajd33106f119516328@mail.gmail.com>
In-Reply-To
<alpine.LFD.0.98.0704162215520.4504@xanadu.home>
On 4/17/07, Nicolas Pitre <nico@cam.org> 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
Previous: Nicolas PitreNext: Nicolas Pitre
Message 3 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.