Re: [PATCH v5] repo_read_index: add config to expect files outside sparse patterns

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 2, 2022, 07:36 UTC
Message-ID: <xmqq1qzkolet.fsf@gitster.g>
In-Reply-To: <20220302043301.1620188-1-newren@gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 17 quoted lines

> Typically with sparse checkouts, we expect files outside the sparsity
> patterns to be marked as SKIP_WORKTREE and be missing from the working
> tree.  Sometimes this expectation would be violated however; including
> in cases such as:
>   * users grabbing files from elsewhere and writing them to the worktree
>     (perhaps by editing a cached copy in an editor, copying/renaming, or
>      even untarring)
>   * various git commands having incomplete or no support for the
>     SKIP_WORKTREE bit[1,2]
>   * users attempting to "abort" a sparse-checkout operation with a
>     not-so-early Ctrl+C (updating $GIT_DIR/info/sparse-checkout and the
>     working tree is not atomic)[3].
> When the SKIP_WORKTREE bit in the index did not reflect the presence of
> the file in the working tree, it traditionally caused confusion and was
> difficult to detect and recover from.  So, in a sparse checkout, since
> af6a51875a ("repo_read_index: clear SKIP_WORKTREE bit from files present
> in worktree", 2022-01-06), Git automatically clears the SKIP_WORKTREE

The reference is a bit off here.  Here is what I get locally:

    af6a51875a (repo_read_index: clear SKIP_WORKTREE bit from files
    present in worktree, 2022-01-14)

and that is in the version I have locally in 'next'.

Show 5 quoted lines

> [1] https://lore.kernel.org/git/xmqqbmb1a7ga.fsf@gitster-ct.c.googlers.com/
> [2] The three long paragraphs in the middle of
>     https://lore.kernel.org/git/CABPp-BH9tju7WVm=QZDOvaMDdZbpNXrVWQdN-jmfN8wC6YVhmw@mail.gmail.com/
> [3] https://lore.kernel.org/git/CABPp-BFnFpzwGC11TLoLs8YK5yiisA5D5-fFjXnJsbESVDwZsA@mail.gmail.com/
> [4] such as the vfsd described in

Here is another difference from the version I have locally in 'next', which I didn't notice that this [4] was misspelt as [1] before applying.

Everything else seems the same, so let's not bother reverting the old one out of 'next' and merging this version after fixing this version up. What we have is good enough modulo [4] vs [1].

Thanks.