From patchwork Thu Apr 1 01:49:38 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Derrick Stolee X-Patchwork-Id: 12176785 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7F5FC433ED for ; Thu, 1 Apr 2021 01:51:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7158660FE9 for ; Thu, 1 Apr 2021 01:51:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231620AbhDABua (ORCPT ); Wed, 31 Mar 2021 21:50:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232958AbhDABuH (ORCPT ); Wed, 31 Mar 2021 21:50:07 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DC2CC061761 for ; Wed, 31 Mar 2021 18:50:06 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id v11so182317wro.7 for ; Wed, 31 Mar 2021 18:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:in-reply-to:references:from:date:subject:fcc :content-transfer-encoding:mime-version:to:cc; bh=EEiLnZcxBnalSrtS0KgvDP7CGUo9RluvCjn0alofKlM=; b=c9Sl1w7XA5U8s4eBcfSa5OIgRuRr+AOzgoZuqZ72V6W6drRQ887VkVRwBXBiTeqMqr hWNIDTSfHj0xOJXdnEyLS3WgWGBPX/RtXwDtiYeF8xn/l7OxVFeofVQdGAMlvN0X2TI9 6bZOxd+lLfHdf9mtxkfx5J4FBBKOKKKYfZRhGDJv1Pc42P3KIbkUAfNEHtZ1XbMiVh5l aWnUk7pKUYycKJ53ADxZskOCojaIipQsGGNGD2gD8aDyBNGlw3CIM+E4VFMelrgHrSpu aSpqofR786ju8WaxhfpXZLIQPpyr+9F0TFzcClahfebqABD+VtTVE8WVgOmJAyiwknGU o+vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:in-reply-to:references:from:date :subject:fcc:content-transfer-encoding:mime-version:to:cc; bh=EEiLnZcxBnalSrtS0KgvDP7CGUo9RluvCjn0alofKlM=; b=Hte92g2Qp9A+3PGXt+crqGRyDTZZAF20dxWr+bhyJRsqmvGYBH/lR7ruoJAjXmUyih duXsiuGtZSPy31FhovMEuv0m1BnkbwXnBKSSHKihZnDy7/768MCRCNV045HJelsUIQJO kHWnzvqEF9MpRI7HJdINv1ozLOFT9wmTfYTAl/PjrqkiKKojY7FL0rALYfeBB5EXLw9S 7SZcrFUJ7rjsvDWknmyK7evlK9Zw+t8yOp1QkhQoN0yvAoXQdxReWNhdo/kaSarHw04j YZy8N6wKyhV24JvoSV5kZOTbEBBniiDGi40SkZDMJ75xAe8CpZwEboZWsscosX5L7+up raGQ== X-Gm-Message-State: AOAM531HGzOnTNC3bApxfkfaZMxdCmiSGpNIoGvswBgo3x1ht14RF+GC zlESfS8xG6UK0R+GFyZcHZB926VO/aw= X-Google-Smtp-Source: ABdhPJzn8jqXZi2mj+VqymEzh0HdCaUqJ36vRoffamDVkH8+GRbuJb/8q1CkDk7GkHkY0MsLkXuV4w== X-Received: by 2002:adf:fb0b:: with SMTP id c11mr6716770wrr.425.1617241805392; Wed, 31 Mar 2021 18:50:05 -0700 (PDT) Received: from [127.0.0.1] ([13.74.141.28]) by smtp.gmail.com with ESMTPSA id p16sm9304963wrt.54.2021.03.31.18.50.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Mar 2021 18:50:05 -0700 (PDT) Message-Id: <7484e085e3426fbcc696e8122de512ab3a846c09.1617241802.git.gitgitgadget@gmail.com> In-Reply-To: References: Date: Thu, 01 Apr 2021 01:49:38 +0000 Subject: [PATCH v2 01/25] sparse-index: API protection strategy Fcc: Sent MIME-Version: 1.0 To: git@vger.kernel.org Cc: newren@gmail.com, gitster@pobox.com, Derrick Stolee , Matheus Tavares Bernardino , Derrick Stolee , Derrick Stolee Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: Derrick Stolee From: Derrick Stolee Edit and expand the sparse-index design document with the plan for guarding index operations with ensure_full_index(). Notably, the plan has changed to not have an expand_to_path() method in favor of checking for a sparse-directory hit inside of the index_path_pos() API. The changes that follow this one will incrementally add ensure_full_index() guards to iterations over all cache entries. Some iterations over the cache entries are not protected due to a few categories listed in the document. Since these are not being modified, here is a short list of the files and methods that will not receive these guards: Looking for non-zero stage: * builtin/add.c:chmod_pathspec() * builtin/merge.c:count_unmerged_entries() * merge-ort.c:record_conflicted_index_entries() * read-cache.c:unmerged_index() * rerere.c:check_one_conflict(), find_conflict(), rerere_remaining() * revision.c:prepare_show_merge() * sequencer.c:append_conflicts_hint() * wt-status.c:wt_status_collect_changes_initial() Looking for submodules: * builtin/submodule--helper.c:module_list_compute() * submodule.c: several methods * worktree.c:validate_no_submodules() Part of the index API: * name-hash.c: lazy init methods * preload-index.c:preload_thread(), preload_index() * read-cache.c: file format methods Checking for correct order of cache entries: * read-cache.c:check_ce_order() Ignores SKIP_WORKTREE entries or already aware: * unpack-trees.c:mark_new_skip_worktree() * wt-status.c:wt_status_check_sparse_checkout() Signed-off-by: Derrick Stolee --- Documentation/technical/sparse-index.txt | 37 ++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/sparse-index.txt b/Documentation/technical/sparse-index.txt index 8d3d80804604..3b24c1a219f8 100644 --- a/Documentation/technical/sparse-index.txt +++ b/Documentation/technical/sparse-index.txt @@ -85,8 +85,41 @@ index, as well. Next, consumers of the index will be guarded against operating on a sparse-index by inserting calls to `ensure_full_index()` or -`expand_index_to_path()`. After these guards are in place, we can begin -leaving sparse-directory entries in the in-memory index structure. +`expand_index_to_path()`. If a specific path is requested, then those will +be protected from within the `index_file_exists()` and `index_name_pos()` +API calls: they will call `ensure_full_index()` if necessary. The +intention here is to preserve existing behavior when interacting with a +sparse-checkout. We don't want a change to happen by accident, without +tests. Many of these locations may not need any change before removing the +guards, but we should not do so without tests to ensure the expected +behavior happens. + +It may be desirable to _change_ the behavior of some commands in the +presence of a sparse index or more generally in any sparse-checkout +scenario. In such cases, these should be carefully communicated and +tested. No such behavior changes are intended during this phase. + +During a scan of the codebase, not every iteration of the cache entries +needs an `ensure_full_index()` check. The basic reasons include: + +1. The loop is scanning for entries with non-zero stage. These entries + are not collapsed into a sparse-directory entry. + +2. The loop is scanning for submodules. These entries are not collapsed + into a sparse-directory entry. + +3. The loop is part of the index API, especially around reading or + writing the format. + +4. The loop is checking for correct order of cache entries and that is + correct if and only if the sparse-directory entries are in the correct + location. + +5. The loop ignores entries with the `SKIP_WORKTREE` bit set, or is + otherwise already aware of sparse directory entries. + +6. The sparse-index is disabled at this point when using the split-index + feature, so no effort is made to protect the split-index API. Even after inserting these guards, we will keep expanding sparse-indexes for most Git commands using the `command_requires_full_index` repository