summaryrefslogtreecommitdiff
path: root/builtin/prune-packed.c
diff options
context:
space:
mode:
authorLibravatar Taylor Blau <me@ttaylorr.com>2021-09-18 12:02:37 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-09-20 11:01:23 -0700
commitd5fdf3073abaa6b968a7eef2ac09835dc4628fc2 (patch)
tree3cea622dcdaf951229c1f1a8de6f90aa17ec8a1a /builtin/prune-packed.c
parentcommit-graph: show "unexpected subcommand" error (diff)
downloadtgif-d5fdf3073abaa6b968a7eef2ac09835dc4628fc2.tar.xz
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>
Diffstat (limited to 'builtin/prune-packed.c')
0 files changed, 0 insertions, 0 deletions