Junio C Hamano <gitster@xxxxxxxxx> 于2023年1月21日周六 00:34写道： > > Elijah Newren <newren@xxxxxxxxx> writes: > > > On Thu, Jan 19, 2023 at 9:34 AM ZheNing Hu via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > >> > >> From: ZheNing Hu <adlternative@xxxxxxxxx> > >> > >> 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. Can this strange design be considered as a bad design of %(if) and %(else) in ref-filter?
