commit-graph: drop top-level --[no-]progress
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 patch 8 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/1 | builtin/commit-graph.c: don't accept common --[no-]progressbuiltin/ | +4 | 2 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [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/[email protected]/
[2]: https://lore.kernel.org/git/[email protected]/
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(-)
Signature · 1 line
2.33.0.96.g73915697e6