Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 于2022年6月28日周二 02:48写道： > > > On Sun, Jun 26 2022, ZheNing Hu via GitGitGadget wrote: > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > Add a new option --format that output index enties > > informations with custom format, taking inspiration > > from the option with the same name in the `git ls-tree` > > command. > > > > --format cannot used with -s, -o, -k, --resolve-undo, > > --deduplicate and --eol. > > > > Signed-off-by: ZheNing Hu <adlternative@xxxxxxxxx> > > --- > > [...] > > +test_expect_success 'git ls-files --format with --debug' ' > > + git ls-files --debug >expect && > > + git ls-files --format="%(path)" --debug >actual && > > + test_cmp expect actual > > +' > > + > > +test_done > > I'm not sure what to make of this. > > In some ways I think this makes more sense than what I suggested in > https://lore.kernel.org/git/220624.86letmi383.gmgdl@xxxxxxxxxxxxxxxxxxx/; > but I had to think for a second about what's going on here. > > In my version I suggested having this work with --debug, but not in this > way, in my version you'd always emit the debug output, and the format > output. > > But here e.g.: > > git ls-files -t --debug > > Will emit "H tag.c" or whatever, but if you add --format the -t option > is silently discarded. > > So the test is relying on "%(path)" being the default format. > > I think extending this to e.g. test what happens with "-t" would be a > good thing, but also in general does combining --format with -t make > sense, and are there other such options where the combination might not > make sense? > Why not we just let -t incompatible with --format? Is this because -t can also be considered a “debug” message, and we often use --debug and -t together? If so, we can just do something like: @@ -238,6 +335,13 @@ static void show_ce(struct repository *repo, struct dir_struct *dir, S_ISGITLINK(ce->ce_mode))) { tag = get_tag(ce, tag); + if (format) { + fputs(tag, stdout); + show_ce_fmt(repo, ce, format, fullname); + print_debug(ce); + return; + } + > So I'm not 100% sure, but I think I'd prefer my version, but I see how > it would get hairy to support, e.g.: > > git ls-files -s --debug --format=... > > Should work, but you'd have to special-case the logic for erroring if -s > is combined with --format. > Agree. it's really weird. > Anyway, I think it would be fine to leave this in whatever state is > easy, the --debug option "just for debugging". > > But re > https://lore.kernel.org/git/CAOLTT8Tc95-aUE+uN2d8QjTJpGpGw6cBJfG+bpmyE55OcXTSRA@xxxxxxxxxxxxxx/ > I think it might be interesting to get --format to a state where we can > remove --debug entirely. > > I.e. in c2a29405105 (t1091/t3705: remove 'test-tool read-cache --table', > 2021-12-22) we could replace some similar test-only code with "git > ls-files". I for one wouldn't mind --debug going away entirely, and have > the t3705-add-sparse-checkout.sh tests use --format instead. > > Or we could keep --debug, but just have it powerful enough to do what > print_debug() is doing now, possibly without "truly internal" stuff like > "ce_flags". Ah, though we just remove these little "useless" atoms, maybe we can add them back later? (not in this patch?) ZheNing Hu
