From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "SZEDER Gábor" <szeder.dev@gmail.com>
Subject: sg/parse-options-subcommand (was: What's cooking in git.git (Aug 2022, #07; Fri, 19))
Date: Sun, 21 Aug 2022 15:25:30 +0200 [thread overview]
Message-ID: <220821.86r1194te1.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqbksfirfm.fsf@gitster.g>
On Fri, Aug 19 2022, Junio C Hamano wrote:
> * sg/parse-options-subcommand (2022-08-19) 20 commits
> - builtin/worktree.c: let parse-options parse subcommands
> - builtin/stash.c: let parse-options parse subcommands
> - builtin/sparse-checkout.c: let parse-options parse subcommands
> - builtin/remote.c: let parse-options parse subcommands
> - builtin/reflog.c: let parse-options parse subcommands
> - builtin/notes.c: let parse-options parse subcommands
> - builtin/multi-pack-index.c: let parse-options parse subcommands
> - builtin/hook.c: let parse-options parse subcommands
> - builtin/gc.c: let parse-options parse 'git maintenance's subcommands
> - builtin/commit-graph.c: let parse-options parse subcommands
> - builtin/bundle.c: let parse-options parse subcommands
> - parse-options: add support for parsing subcommands
> - parse-options: drop leading space from '--git-completion-helper' output
> - parse-options: clarify the limitations of PARSE_OPT_NODASH
> - parse-options: PARSE_OPT_KEEP_UNKNOWN only applies to --options
> - api-parse-options.txt: fix description of OPT_CMDMODE
> - t0040-parse-options: test parse_options() with various 'parse_opt_flags'
> - t5505-remote.sh: check the behavior without a subcommand
> - t3301-notes.sh: check that default operation mode doesn't take arguments
> - git.c: update NO_PARSEOPT markings
>
> Introduce the "subcommand" mode to parse-options API and update the
> command line parser of Git commands with subcommands.
>
> Will merge to 'next'?
> source: <20220819160411.1791200-1-szeder.dev@gmail.com>
I looked it over is detail this time around (and meant to for v1). I
think that all of what I mentioned in my review can be left for later,
except maybe the subtle change in "case" label fall-through pointed out
in [1], but it doesn't introduce any functional changes. So if SZEDER is
happy with it I'm fine with it.
1. https://lore.kernel.org/git/220819.86h7285a1o.gmgdl@evledraar.gmail.com/
next prev parent reply other threads:[~2022-08-21 13:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-20 2:23 What's cooking in git.git (Aug 2022, #07; Fri, 19) Junio C Hamano
2022-08-21 13:25 ` Ævar Arnfjörð Bjarmason [this message]
2022-08-21 13:30 ` tl/trace2-config-scope (was: What's cooking in git.git (Aug 2022, #07; Fri, 19)) Ævar Arnfjörð Bjarmason
2022-08-22 11:06 ` pw/rebase-keep-base-fixes, was Re: What's cooking in git.git (Aug 2022, #07; Fri, 19) Johannes Schindelin
2022-08-22 11:16 ` en/ort-unused-code-removal, " Johannes Schindelin
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=220821.86r1194te1.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.