]> git.ipfire.org Git - thirdparty/git.git/commit
builtin/commit-graph.c: don't accept common --[no-]progress
authorTaylor Blau <me@ttaylorr.com>
Sat, 18 Sep 2021 16:02:37 +0000 (12:02 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 20 Sep 2021 18:01:23 +0000 (11:01 -0700)
commitd5fdf3073abaa6b968a7eef2ac09835dc4628fc2
tree3cea622dcdaf951229c1f1a8de6f90aa17ec8a1a
parent367c5f36a6a0fa7f8f706b10f9bb2f0e28baaa1a
builtin/commit-graph.c: don't accept common --[no-]progress

In 84e4484f12 (commit-graph: use parse_options_concat(), 2021-08-23) we
unified common options of commit-graph's subcommands into a single
"common_opts" array.

But 84e4484f12 introduced a behavior change which is to accept the
"--[no-]progress" option before any sub-commands, e.g.,

    git commit-graph --progress write ...

Prior to that commit, the above would error out with "unknown option".

There are two issues with this behavior change. First is that the
top-level --[no-]progress is not always respected. This is because
isatty(2) is performed in the sub-commands, which unconditionally
overwrites any --[no-]progress that was given at the top-level.

But the second issue is that the existing sub-commands of commit-graph
only happen to both have a sensible interpretation of what `--progress`
or `--no-progress` means. If we ever added a sub-command which didn't
have a notion of progress, we would be forced to ignore the top-level
`--[no-]progress` altogether.

Since we haven't released a version of Git that supports --[no-]progress
as a top-level option for `git commit-graph`, let's remove it.

Suggested-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/commit-graph.c