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

Re: [PATCH] doc: mention bigFileThreshold for packing

From
Christian Walther <cwalther@gmx.ch>
Date
Feb 10, 2021, 21:43 UTC
Message-ID
<F63929A8-7BC9-43A7-9E7B-118433F62588@gmx.ch>
In-Reply-To
<xmqqim70zzaf.fsf@gitster.c.googlers.com>
Junio C Hamano wrote:
Show 5 quoted lines
> I doubt that the description of --window/--depth command line
> options, for both repack and pack-objects, is the best place to add
> this "Note".  Even if we were to add it as an appendix to these
> places, please do not break the flow of explanation by inserting it
> before the description of the default values of these options.
OK. That was where I would have looked for it, because it explains why --window wasn't effective in my attempts to get better compression, but I don't insist on it - any place would have worked, as I read both manpages back and forth several times.
In git-repack.txt, there is a "Configuration" section at the bottom, I guess it would fit there? There is none in git-pack-objects.txt, but I could add it. What do you think?
Show 9 quoted lines
>>    I recently spent a lot of time trying to figure out why git repack would
>>    create huge packs on some clones of my repository and small ones on
>>    others
> 
> Not related to the contents of the patch, but I am somewhat curious
> to know what configuration resulted in the "huge" ones and "small"
> ones.  Documentation/config/core.txt::core.bigFileThreashold may be
> helped by addition of a success story, and the configuration for the
> "small" ones may be a good place to start.
The "huge" repository had bigFileThreshold = 1m. That was set by SubGit when converting from Subversion, for reasons unknown to me (see some discussion at https://support.tmatesoft.com/t/reduce-repository-size/2551 and https://issues.tmatesoft.com/issue/SGT-604). The result is a pack file of about 3 GB.
The "small" repository has it unset, so the default 512m applies, resulting in a pack file of about 50 MB.
What causes the huge difference is that the repository contains a "changelog" file that changes in almost every commit and has grown to 2.4 MB over 10000 commits. So it exists in about that many different versions, of which about 6000 are larger than 1 MB, but they only differ from each other by successive addition of small pieces.
I'm not sure if that makes for a good success story. 1m seems a rather extreme value to me. If you think so, I can try to come up with something.
Thanks
 Christian
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 5 in “doc: mention bigFileThreshold for packing”
  1. doc: mention bigFileThreshold for packingChristian Walther via GitGitGadget, Feb 9, 2021
  2. Junio C HamanoFeb 9, 2021
  3. Christian WaltherFeb 10, 2021
  4. Junio C HamanoFeb 10, 2021
  5. doc: mention bigFileThreshold for packingChristian Walther via GitGitGadget, Feb 21, 2021

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.