[PATCH 0/1] commit-graph: drop top-level --[no-]progress

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@szeder.dev/ [2]: https://lore.kernel.org/git/YUUQzswYL5x74Tps@coredump.intra.peff.net/

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(-)