This patch provides one way to fix an issue that SZEDER described in [1]. The issue is that `git commit-graph` began accepting `--[no-]progress` as a top-level argument as an unintentional side-effect of 84e4484f12 (commit-graph: use parse_options_concat(), 2021-08-23). Some discussion beginning at [2] indicates a couple of reasons why this is undesirable, and they are summarized in the patch below. But most importantly, if we do want to get rid of the top-level `--[no-]progress`, then we should act quickly to do it before 84e4484f12 (which currently isn't tagged) is released. An open question is whether the same should be done for the multi-pack-index command, whose top-level support for `--[no-]progress` was released in v2.32.0 with 60ca94769c (builtin/multi-pack-index.c: split sub-commands, 2021-03-30). [1]: https://lore.kernel.org/git/20210917211337.GC2118053@xxxxxxxxxx/ [2]: https://lore.kernel.org/git/YUUQzswYL5x74Tps@xxxxxxxxxxxxxxxxxxxxxxx/ Taylor Blau (1): builtin/commit-graph.c: don't accept common --[no-]progress builtin/commit-graph.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.33.0.96.g73915697e6
