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

What happens when the repository is bigger than gc.autopacklimit * pack.packSizeLimit?

From
Dale R. Worley <worley@alum.mit.edu>
Date
Aug 27, 2014, 19:36 UTC
Message-ID
<201408271936.s7RJarOh011358@hobgoblin.ariadne.com>

[Previously sent to the git-users mailing list, but it probably should be addressed here.]

A number of commands invoke "git gc --auto" to clean up the repository when there might be a lot of dangling objects and/or there might be far too many unpacked files. The manual pages say:

    git gc:
       --auto
           With this option, git gc checks whether any housekeeping is
           required; if not, it exits without performing any work. Some git
           commands run git gc --auto after performing operations that could
           create many loose objects.
           Housekeeping is required if there are too many loose objects or too
           many packs in the repository. If the number of loose objects
           exceeds the value of the gc.auto configuration variable, then all
           loose objects are combined into a single pack using git repack -d
           -l. Setting the value of gc.auto to 0 disables automatic packing of
           loose objects.
    git config:
       gc.autopacklimit
           When there are more than this many packs that are not marked with
           *.keep file in the repository, git gc --auto consolidates them into
           one larger pack. The default value is 50. Setting this to 0
           disables it.

What happens when the amount of data in the repository exceeds gc.autopacklimit * pack.packSizeLimit? According to the documentation, "git gc --auto" will then *always* repack the repository, whether it needs it or not, because the data will require more than gc.autopacklimit pack files.

And it appears from an experiment that this is what happens. I have a repository with pack.packSizeLimit = 99m, and there are 104 pack files, and even when "git gc" is done, if I do "git gc --auto", it will do git-repack again.

Looking at the code, I see:
builtin/gc.c:
static int too_many_packs(void)
{
	struct packed_git *p;
	int cnt;
	if (gc_auto_pack_limit <= 0)
		return 0;
	prepare_packed_git();
	for (cnt = 0, p = packed_git; p; p = p->next) {
		if (!p->pack_local)
			continue;
		if (p->pack_keep)
			continue;
		/*
		 * Perhaps check the size of the pack and count only
		 * very small ones here?
		 */
		cnt++;
	}
	return gc_auto_pack_limit <= cnt;
}
Yes, perhaps you *should* check the size of the pack!
What is a good strategy for making this function behave as we want it to?
Dale
Next: Jeff King
Message 1 of 7 in “What happens when the repository is bigger than gc.autopacklimit * pack.packSizeLimit?”
  1. Dale R. WorleyAug 27, 2014
  2. Jeff KingAug 27, 2014
  3. Dale R. WorleyAug 29, 2014
  4. Jeff KingAug 29, 2014
  5. Dale R. WorleyAug 29, 2014
  6. Junio C HamanoAug 27, 2014
  7. Dale R. WorleyAug 29, 2014

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.