Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> 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 >> 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.
