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.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 C64AB1F8C6 for ; Mon, 30 Aug 2021 20:09:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234794AbhH3UJp (ORCPT ); Mon, 30 Aug 2021 16:09:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234204AbhH3UJo (ORCPT ); Mon, 30 Aug 2021 16:09:44 -0400 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4125C061575 for ; Mon, 30 Aug 2021 13:08:50 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id o16-20020a9d2210000000b0051b1e56c98fso19901624ota.8 for ; Mon, 30 Aug 2021 13:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IwEtU9UhtAsEvLTxJTWAAAdLZmJ27Z2vtWXQ6LTAyz4=; b=gGD45qJKJ2d6Wn+3r8mBQDYXMMFABjS7Jcx/pfeGF+51bZMVZgqMNz7FOby9qzppsc DSw4Xgq+pjowVmDje8cfrPWFAybJvRsU+pKDishz4jtjvYnh32eYUZi9icEoExYdBRtX g8c7djz0wY9vdvgpfkA/k1S3qyqGYwIfmu34BsahFXlOxgs5vN2xHJ6OcwVQFEmzL/L0 ox5p8UJhmRMgArAT2+7N6e4Y8qtD3ioLkOK8fdVHhZlv44TOKJRraokW7TJwu/aQlMNF SHS3BiFVNM6GqCx/3QCFTIh0PbUdr+KTbQZrcDJRQgt1FXwVCYDoQo5APlQSqCf/ZLpF 5Ggw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IwEtU9UhtAsEvLTxJTWAAAdLZmJ27Z2vtWXQ6LTAyz4=; b=Hd/mpbiVhaB9Ul2TRcgVdhnP+rJ5A/e7Re5d3MfIXd5UahqugA3n71l3a3QCCmwZe/ lp4CwMtVygh0FS6EZSXCVwGXSdY4crv4wbnCL0/pRq0CzdruHlu1LlXjB8g7Js3vKJkt 8Qkab27vCnxRFZeyS+gW2B2NZF2AUL+o3jU94YdIXKTp9WSnMtsjWK+CVjwQctHGwOOG Wc0AtDgf42mYtNF8YiPpfv+z5eifVTPqzNr09MJkX3rE0ZctiA8vdhHVDe3Bd5G1LEhG QMiYv74teLXRD4WHFIKDITpl9fm/M+IFbt+D8Cy/VXILgMOfR2yBvDvAz41iVXkmwvtS 0tsg== X-Gm-Message-State: AOAM531V6Mc8KG2musxCpiWJsrHi7eWgjTFL1AqKyrFlPKBJlD7Zh0Wl QsOlfDuqQkTS6IunkEWSLiEkHq54iH2pQD1Q/pCsd2XYm0M= X-Google-Smtp-Source: ABdhPJx+rUYS/c/+3UapD2Vk0wGp6BDe5/1fhjZDz3VV1pdw1f49+BQL+ERmBPOx+3BJG6NGQMX5mdgabXDig2bNSYY= X-Received: by 2002:a05:6830:b8e:: with SMTP id a14mr20854629otv.162.1630354130122; Mon, 30 Aug 2021 13:08:50 -0700 (PDT) MIME-Version: 1.0 References: <2870fcb8-a356-c2c2-d084-b560326e1ad4@gmail.com> In-Reply-To: <2870fcb8-a356-c2c2-d084-b560326e1ad4@gmail.com> From: Elijah Newren Date: Mon, 30 Aug 2021 13:08:39 -0700 Message-ID: Subject: Re: [PATCH v4 04/10] sparse-index: use WRITE_TREE_MISSING_OK To: Derrick Stolee Cc: Derrick Stolee via GitGitGadget , Git Mailing List , Junio C Hamano , Matheus Tavares Bernardino , Johannes Schindelin , Eric Sunshine , =?UTF-8?Q?Ren=C3=A9_Scharfe?= , Derrick Stolee , Derrick Stolee Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Aug 30, 2021 at 6:19 AM Derrick Stolee wrote: > > On 8/27/2021 5:33 PM, Elijah Newren wrote: > > On Tue, Aug 24, 2021 at 2:51 PM Derrick Stolee via GitGitGadget > > wrote: > >> > >> From: Derrick Stolee > >> > >> When updating the cache tree in convert_to_sparse(), the > >> WRITE_TREE_MISSING_OK flag indicates that trees might be computed that > >> do not already exist within the object database. > > > > Okay. > > > >> This happens in cases > >> such as 'git add' creating new trees that it wants to store in > >> anticipation of a following 'git commit'. > > > > This doesn't make any sense to me. Does 'git add' call > > convert_to_sparse()? I don't see why it would; wouldn't the calls to > > convert_to_sparse() come via sparse-checkout init/set commands? If > > I'm correct on that, and 'git add' wants to create new trees, then by > > the time convert_to_sparse() is called in some subsequent git > > operation, then convert_to_sparse would already have the trees it > > needs. > > If someone adds a change outside the sparse-checkout cone, then the > index is expanded in-memory, then is converted to sparse when the > index is written again. Ah, I missed that convert_to_sparse() is called from write_index(), and that we are dealing with a single operation that does a sparse->full (in memory)->sparse roundtrip. Thanks for clearing that up. > > I thought the reason you would need this is someone modified and > > staged a change to a file underneath a directory that will be > > sparsified away; at the time of convert_to_sparse(), a tree object may > > not have yet been written for the new tree with the newly modified > > file (because those tend to be written at commit time), but you'd need > > it at the time you sparsified. > > Yes. I think we are trying to say the same thing. While writing this, I was thinking in terms of the `git add` being done when the index was full (both in memory and on disk), and then a later `git sparse-checkout ...` command would invoke the convert_to_sparse(). I didn't fully catch the nuances here. Thanks for bringing me up to speed.