From: Elijah Newren <newren@gmail.com>
Date: Sat, 14 Jan 2023 03:00:32 GMT
Subject: Re: [PATCH] ls-files: add %(skipworktree) atom to format option
Message-ID: <CABPp-BFEKqU2YWEk=NT2xA_cO=rj_EgjqzYsuxDGwPon18dq8Q@mail.gmail.com>
In-Reply-To: <CAOLTT8RNWJLA_UvoMA_MktkEmLSjJrx7E6Khy97cHhVFXPQD2A@mail.gmail.com>

On Fri, Jan 13, 2023 at 8:50 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Elijah Newren <newren@gmail.com> 于2023年1月12日周四 18:00写道：
> >
> > On Wed, Jan 11, 2023 at 7:42 AM ZheNing Hu via GitGitGadget
> > <gitgitgadget@gmail.com> wrote:
> > >
[...]
> > The "and removed from working tree" portion of this sentence is
> > superfluous.  (And actually makes it harder to understand, I had to
> > try to think through a bunch of cases to try to figure out why you
> > might be trying to add some extra qualifier.)
> >
>
> I just quoted the definition of SKIP_WORKTREE from
> Documentation/technical/sparse-checkout.txt:
>
>     SKIP_WORKTREE: When tracked files do not match the sparse specification and
>       are removed from the working tree, the file in the index is marked
>       with a SKIP_WORKTREE bit.

Ah, thanks for pointing out the error.  This should probably be reworded to:

SKIP_WORKTREE: When a tracked file which is unmodified does not match
        the sparsity patterns, it is removed from the working tree and
        the file in the index is marked with a SKIP_WORKTREE bit (to
        distinguish the missing file from an unstaged deletion).

[...]
> To be honest, right now I think %(skipworktree) just refines the
> --format option's ability to read the index entry SKIP_WORKTREE
> flag bits. It is probably still worth keeping.

I'm not opposed to the idea of a special skipworktree formatting in
conjunction with ls-files' --format option, so long as it has
alternate rationale and isn't worded to suggest it supersedes `git
ls-files -t` for all sparse-checkout uses.