diff options
author | Taylor Blau <me@ttaylorr.com> | 2021-09-18 12:02:37 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2021-09-20 11:01:23 -0700 |
commit | d5fdf3073abaa6b968a7eef2ac09835dc4628fc2 (patch) | |
tree | 3cea622dcdaf951229c1f1a8de6f90aa17ec8a1a /builtin/prune-packed.c | |
parent | commit-graph: show "unexpected subcommand" error (diff) | |
download | tgif-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