Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > However, manually going over: > > git grep -e OPT_HIDDEN_BOOL -e PARSE_OPT_HIDDEN > > Shows many options we don't want to show in completion either, > e.g. "git am --binary" or "git branch -l". Many of these are internal, > deprecated, or no-ops. There's also things like "git difftool > --prompt" (the default behavior) which are arguably pointless to add, > we just have "--no-prompt" to inverse the default. Yeah, and I believe some hidden ones are hidden because they encourage bad workflows (like --allow-empty-message) especially when used interactively, and they aren't marked with nocomplete only because there wasn't any such bit back when they were marked hidden. In any case, those that are hidden for such a reason now need to be marked with both hidden and nocomplete, which is a small one-time price to pay to make the meaning of these two bits saner. So I quite like the direction in which this patch is taking the underlying mechanism. A "blind" translation that is far safer than your patch may first * update the code so that ones with hidden-bit are completed * update the data so that ones currently have hidden bit but not nocomplete bit gain nocomplete bit as well. That would give us a saner mechanism without changing the behaviour. And then we can make policy decisions for each option separately for the merit of keeping it hidden (i.e. excluding from short help to unclutter) and/or keeping it not completed (i.e. discouraging its use in an interactive session). As I think some of the hidden ones also have nocomplete and others do not have nocomplete merely by historical accident, the way this patch changes behaviour for some options (namely, the hidden ones that did not have nocomplete not because they wanted to be completed but because there wasn't such an option to exclude them from completion previously and because it was sufficient to mark them as hidden to exclude them from completion) means making policy decisions while updating the mechanism that allows us to express our policy decisions. I do not think we should conflate the two in the same patch.
