From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id E7A301F5AE for ; Sun, 2 May 2021 16:55:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232230AbhEBQ4o (ORCPT ); Sun, 2 May 2021 12:56:44 -0400 Received: from cloud.peff.net ([104.130.231.41]:42522 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229678AbhEBQ4o (ORCPT ); Sun, 2 May 2021 12:56:44 -0400 Received: (qmail 31429 invoked by uid 109); 2 May 2021 16:55:52 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Sun, 02 May 2021 16:55:52 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 19993 invoked by uid 111); 2 May 2021 16:55:52 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Sun, 02 May 2021 12:55:52 -0400 Authentication-Results: peff.net; auth=none Date: Sun, 2 May 2021 12:55:51 -0400 From: Jeff King To: Bagas Sanjaya Cc: Git Users Subject: Re: "Unpacking objects" question Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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) -Peff