Re: [PATCH v2 2/2] ls-files: add %(skipworktree) atom to format option

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2023, 16:34 UTC
Message-ID: <xmqqcz79xizc.fsf@gitster.g>
In-Reply-To: <CABPp-BGLmhoHAcuLoz_yQ4TmNBvDU6Ehymy_3rh0wguSw0hjGw@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 23 quoted lines

> On Thu, Jan 19, 2023 at 9:34 AM ZheNing Hu via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>
>> From: ZheNing Hu <adlternative@gmail.com>
>>
>> Because sometimes we want to check if the files in the
>> index match the sparse specification, so introduce
>> "%(skipworktree)" atom to git ls-files `--format` option.
>> When we use this option, if the file match the sparse
>> specification, it will output "1", otherwise, output
>> empty string "".
>
> Why is that output format useful?  It seems like it'll just lead to
> bugs, or someone re-implementing the same field with a different name
> to make it useful in the future.  In particular, if there are multiple
> boolean fields and someone specifies e.g.
>    git ls-files --format="%(path) %(skipworktree) %(intentToAdd)"
> and both boolean fields are displayed the same way (either a "1" or a
> blank string), and we see something like:
>    foo.c 1
>    bar.c 1
> Then how do we know if foo.c and bar.c are SKIP_WORKTREE or
> INTENT_TO_ADD?  The "1" could have come from either field.

Perhaps it becomes useful in conjunction with %(if) and friends, when they become avaiable?

Until then, I agree that the output format looks pretty klunky. The calling scripts still can do

	--format='%(path) A=%(A) B=%(B) C=%(C)'

and take an empty value as false, though.