Re: [PATCH 2/5] cat-file: mention --unordered along with --batch-all-objects

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

In fact, it _would_ be a bug to make it a CMDMODE if --batch were
correctly marked as one (but it is not sufficient to reason the other
way; --batch without --batch-all-objects is still mutually exclusive
with -t, etc).

 > What really makes things confusing, IMHO, is the --textconv and --filter

quoted

options. They are marked as CMDMODEs, and they are indeed mutually
exclusive with -t, etc. But they also work with --batch, which is itself
a different mode.

So I don't think OPT_CMDMODE could ever present this complete set of
rules, because they are not all mutually exclusive with each other. But
I think calling "--batch-all-objects" a mode is just muddying the waters
even further.

I think we've got some different understanding of what a CMDMODE
means. --batch-all-objects should be a cmdmode, but --batch, --buffer
etc. can't be. Similarly it's not a bug that --filters and --textconv
are cmdmodes, but you think that's bad.

Among options[] elements, "batch" and "batch-check" take &batch, and
they are obviously mutually exclusive.  "batch-all-objects" can flip
the batch.all_objects flag to affect operations that use &batch
(namely, these two), so it is more like a modifier and can never be
a cmdmode.

Is "git cat-file -t tag --batch" a valid way to invoke the command?
Are there options (like "-t" in the above example) that are marked
with OPT_CMDMODE that can be used with "--batch" or "--batch-check"?

If the answer is "no", then "--batch" and "--batch-check" could also
be command modes, but I suspect OPT_CMDMODE() does not have enough
flexibility to say "use the &opt to record which command mode is
requested, and by the way, there is this extra pointer &batch to
stuff necessary information in and use this callback to fill it", so
even if "--batch" and "--batch-check" are incompatible with existing
command modes, it needs a bit or preparatory work to make them.