Re: [PATCH v5] repo_read_index: add config to expect files outside sparse patterns
- From
Elijah Newren <newren@gmail.com>
- Date
- Mar 2, 2022, 08:01 UTC
- Message-ID
- <CABPp-BFqJGHDMz744Q7FV22tW6dpGNoBwAW=P1HZE6PtZeHN6A@mail.gmail.com>
- In-Reply-To
- <xmqq1qzkolet.fsf@gitster.g>
On Tue, Mar 1, 2022 at 11:37 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 27 quoted lines
>
> Elijah Newren <newren@gmail.com> writes:
>
> > 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'.Ugh, forgot to update the date when I updated the reference when you pointed that out.
Show 9 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.
Sorry, I hadn't noticed you merging to next, and I saw in the irc logs the discussion about this 1 vs. 4 between you and jrnieder so I thought I'd fix it.
> 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].
Sounds good.