Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > This option is designed to be used by git-completion.bash. For many > simple cases, what we do in there is usually > > __gitcomp "lots of completion options" > > which has to be manually updated when a new user-visible option is > added. With support from parse-options, we can write > > __gitcomp "$(git command --git-completion-helper)" > > and get that list directly from the parser for free. Dangerous/Unpopular > options could be hidden with the new "NO_GITCOMP" flag. > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> > --- > parse-options.c | 37 +++++++++++++++++++++++++++++++++++++ > parse-options.h | 6 ++++-- > 2 files changed, 41 insertions(+), 2 deletions(-) I do not know if you need PARSE_OPT_NO_INTERNAL_GITCOMP. The only way to trigger this is by passing a rather long option (intended to be used only by scripts), so unlike PARSE_OPT_NO_INTERNAL_HELP which was an escape hatch to free a short-and-sweet "-h" to be retargetted by a selected few commands, there may not be need for it. Some day when everybody uses parse-options, it would be trivially correct to declare that this is the right approach ;-) I am not sure how much of the current completion script's hardcoded option list can be reduced with this approach with today's code, given that the bigger ones (diff and log family) are not using parse-options API at all, but for the ones that already do use parse-options, I think this makes sense. Thanks for a fun read ;-)
