From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Cc: peff@peff.net, szeder.dev@gmail.com, avarab@gmail.com,
dstolee@microsoft.com
Subject: [PATCH 0/1] commit-graph: drop top-level --[no-]progress
Date: Sat, 18 Sep 2021 12:02:34 -0400 [thread overview]
Message-ID: <cover.1631980949.git.me@ttaylorr.com> (raw)
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(-)
--
2.33.0.96.g73915697e6
next reply other threads:[~2021-09-18 16:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-18 16:02 Taylor Blau [this message]
2021-09-18 16:02 ` [PATCH 1/1] builtin/commit-graph.c: don't accept common --[no-]progress Taylor Blau
2021-09-20 12:46 ` Derrick Stolee
2021-09-20 15:02 ` Taylor Blau
2021-09-20 21:24 ` [PATCH 0/1] commit-graph: drop top-level --[no-]progress Junio C Hamano
2021-09-20 21:39 ` Taylor Blau
2021-09-21 18:19 ` Ævar Arnfjörð Bjarmason
2021-09-21 20:38 ` Taylor Blau
2021-09-22 16:22 ` Junio C Hamano
2021-09-21 3:55 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1631980949.git.me@ttaylorr.com \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).