list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Bagas Sanjaya <>
Cc: Git Users <>
Subject: Re: "Unpacking objects" question
Date: Sun, 2 May 2021 12:55:51 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, May 02, 2021 at 06:06:57PM +0700, Bagas Sanjaya wrote:

> Recently I stumbled upon git unpack-objects documentation, which says:
> > Read a packed archive (.pack) from the standard input, expanding the objects contained within and writing them into the repository in "loose" (one object per file) format.
> However, I have some questions:
> 1. When I do git fetch, what is the threshold/limit for "Unpacking objects",
>    in other words what is the minimum number of objects for invoking
>    "Resolving deltas" instead of "Unpacking objects"?
> 2. Can the threshold between unpacking objects and resolving deltas be
>    configurable?

See the fetch.unpackLimit config. The default is 100 objects.

> 3. Why in some cases Git do unpacking objects where resolving deltas
>    can be done?

I don't know if the documentation discusses this tradeoff anywhere, but
off the top of my head:

  - storing packs can be more efficient in disk space (because of deltas
    within the pack, but also fewer inodes for small objects). This
    effect is bigger the more objects you have.

  - storing packs can be less efficient, because thin packs will be
    completed with duplicates of already-stored objects. The overhead is
    bigger the fewer objects you have.

Which I suspect is the main logic driving the object count (I didn't dig
in the history or the archive, though; you might find more discussion
there). AFAIK the number 100 doesn't have any real scientific basis.

There are some other subtle effects, too:

  - storing packs from the wire may make git-gc more efficient (you can
    often reuse deltas sent by the other side)

  - storing packs from the wire may produce a worse outcome after
    git-gc, because you are reusing deltas produced by the client for
    their push (who might not have spent as much CPU looking for them as
    you would)


  reply	other threads:[~2021-05-02 16:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-02 11:06 Bagas Sanjaya
2021-05-02 16:55 ` Jeff King [this message]
2021-05-03  1:22   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: "Unpacking objects" question' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for project(s) associated with this inbox:

AGPL code for this site: git clone