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

From: Jeff King <peff@peff.net>
Date: Oct 8, 2021, 21:44 UTC
Message-ID: <YWC7rF4mpU9W6CbI@coredump.intra.peff.net>
In-Reply-To: <xmqqo87zjlwt.fsf@gitster.g>

On Fri, Oct 08, 2021 at 01:34:26PM -0700, Junio C Hamano wrote:

Show 27 quoted lines

> >> 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.

Yes, it would definitely need that extension. But it's also weirder than that. --textconv is an OPT_CMDMODE(), because it is mutually exclusive with "-t", etc. But it is not exclusive with "--batch". So there is not a single set of mutually exclusive cmdmodes. There are three sets:

  1. single-object options like "-t", "-p", etc

  2. --textconv and --filters, which can take a single object or batch
     input

  3. batch options like --batch-check --batch

(1) is mutually exclusive with (2) and (3), but the latter two are not exclusive with each other.

The current code uses OPT_CMDMODE() for (1) and (2), and then manually enforces the exclusion between (1) and (3). But IMHO it is (2) that is the odd-man out, in that it can be its own mode or a modifier, and it probably should not be OPT_CMDMODE() (but from the end-user perspective, that is OK, though it may influence how we document or group things).

I do not think talking about --batch-all-objects makes sense here. As you said above (and I said already several times), it is a modifier for --batch/--batch-check. Making it into a CMDMODE does not break anything (currently), but:

  - it does not really help; it only makes sense with batch options, and
    we already must manually catch those interacting with single-object
    options (because making them OPT_CMDMODE does not work for the
    reasons above).

  - if we _were_ to make the batch options CMDMODEs, then it would be
    doing the wrong thing (though I don't foresee that happening because
    of those same reasons)

  - if we allowed "--textconv --batch --batch-all-objects", then it
    would likewise do the wrong thing (by conflicting with --textconv's
    CMDMODE). We disallow that now, but it is a potentially well-formed
    request (show all objects, textconv-ing blobs). It's not useful
    enough for anybody to have cared, but I think it shows why the
    semantic distinction of treating --batch-all-objects as a
    batch-option and not itself a mode is important.

-Peff