From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Abhradeep Chakraborty" <chakrabortyabhradeep79@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Eric Sunshine" <sunshine@sunshineco.com>,
git <git@vger.kernel.org>
Subject: Re: [PATCH v4 2/2] parse-options.c: add style checks for usage-strings
Date: Tue, 1 Mar 2022 12:08:01 +0530 [thread overview]
Message-ID: <20220301063801.26732-1-chakrabortyabhradeep79@gmail.com> (raw)
In-Reply-To: <xmqqzgma287n.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> wrote:
> I also think Dscho simply overreacted only because the check broke
> an in-flight topic that is from his group, which is not universally
> built, and the tests in it was written in such a way that the error
> output from the embedded check was not immediately available when
> run in the CI, making it harder to debug. None of that is a fault
> in the approach of using the embedded check.
>
> If the embedded check were there from the beginning, together with
> tons of the existing checks done by parse_options_check(), the
> developers themselves of the in-flight topic(s) would have caught
> the problem, even before it hit the public CI. I am very sure Dscho
> wouldn't have complained or even noticed that you added a new check
> to the parse_options_check().
Hmm, that's true.
> (2) Rethink if parse_options_check() can be made optional at
> runtime, which would (a) allow our test to enable it, and allow
> us to test all code paths that use parse_options() centrally,
> and (b) allow us to bypass the check while the end-user runs
> "git", to avoid overhead of checking the same option[] array,
> which does not change between invocations of "git", over and
> over again all over the world.
>
> We may add the check back to parse_options_check() after doing
> the above. There are already tons of "check sanity of what is
> inside option[]" in there, and it would be beneficial if we can
> separate out from parse_options_start() the sanity checking
> code, regardless of this topic.
>
> (3) While (2) is ongoing, we can let people also explore static
> analysis possibilities.
I agree with you. But I think these two points(specially (2)) deserve
a dedicated discussion/patch thread. Because, the latest version of this
patch series (actually this patch series itself) only cares about the
`usage strings`.
So, I argue you to not discard the last commit for now. As you said `There are
already tons of "check sanity of what is inside option[]"`, integrating
one more sanity check would not affect it. I am saying it not because
I made that commit. The discussion or patch integration of (2) and (3)
may take few weeks (or more than a month may be; I also would like to
take part/contribute to that discussion/PR). I fear that another
set of invalid usage-strings would be added in that time. In that case,
we have to make another commit/PR for correcting those strings - disrupting
the purpose of this first commit you are willing to merge.
As Ævar also said -
> I think with in-flight concerns with (0) and (1) addressed what we have
> here is really good enough for now, and we could just add it to the
> existing parse_options_check() without needing (2) and (3) at this
> point.
Thanks :)
next prev parent reply other threads:[~2022-03-01 6:38 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 17:02 [PATCH] add usage-strings ci check and amend remaining usage strings Abhradeep Chakraborty via GitGitGadget
2022-02-21 14:51 ` Abhradeep Chakraborty
2022-02-21 15:39 ` Ævar Arnfjörð Bjarmason
2022-02-21 17:15 ` Junio C Hamano
2022-02-21 17:33 ` Abhradeep Chakraborty
2022-02-21 18:52 ` Ævar Arnfjörð Bjarmason
2022-02-22 10:57 ` Johannes Schindelin
2022-02-22 12:37 ` Ævar Arnfjörð Bjarmason
2022-02-22 13:42 ` [cocci] " Julia Lawall
2022-02-22 14:03 ` Abhradeep Chakraborty
2022-02-22 15:47 ` Abhradeep Chakraborty
2022-02-25 15:30 ` Johannes Schindelin
2022-02-25 16:16 ` Ævar Arnfjörð Bjarmason
2022-02-26 4:22 ` Abhradeep Chakraborty
2022-02-26 8:55 ` Julia Lawall
2022-02-25 15:03 ` [cocci] " Johannes Schindelin
2022-02-25 15:36 ` Julia Lawall
2022-02-25 16:28 ` Ævar Arnfjörð Bjarmason
2022-02-22 10:25 ` Abhradeep Chakraborty
2022-02-22 15:58 ` [PATCH v2] add usage-strings " Abhradeep Chakraborty via GitGitGadget
2022-02-22 17:16 ` Eric Sunshine
2022-02-23 11:59 ` Abhradeep Chakraborty
2022-02-23 21:17 ` Junio C Hamano
2022-02-23 21:20 ` Eric Sunshine
2022-02-24 6:26 ` Abhradeep Chakraborty
2022-02-23 14:27 ` [PATCH v3 0/2] add usage-strings ci " Abhradeep Chakraborty via GitGitGadget
2022-02-23 14:27 ` [PATCH v3 1/2] amend remaining usage strings according to style guide Abhra303 via GitGitGadget
2022-02-23 14:27 ` [PATCH v3 2/2] parse-options.c: add style checks for usage-strings Abhradeep Chakraborty via GitGitGadget
2022-02-25 5:23 ` [PATCH v4 0/2] add usage-strings ci check and amend remaining usage strings Abhradeep Chakraborty via GitGitGadget
2022-02-25 5:23 ` [PATCH v4 1/2] amend remaining usage strings according to style guide Abhradeep Chakraborty via GitGitGadget
2022-02-25 5:23 ` [PATCH v4 2/2] parse-options.c: add style checks for usage-strings Abhradeep Chakraborty via GitGitGadget
2022-02-25 6:13 ` Junio C Hamano
2022-02-25 8:08 ` Abhradeep Chakraborty
2022-02-25 17:06 ` Junio C Hamano
2022-02-26 3:57 ` Abhradeep Chakraborty
2022-02-25 15:36 ` Johannes Schindelin
2022-02-25 16:01 ` Abhradeep Chakraborty
2022-02-26 1:36 ` Junio C Hamano
2022-02-26 6:08 ` Junio C Hamano
2022-02-26 6:57 ` Abhradeep Chakraborty
2022-02-27 19:15 ` Junio C Hamano
2022-02-28 7:39 ` Abhradeep Chakraborty
2022-02-28 17:48 ` Junio C Hamano
2022-02-28 19:32 ` Ævar Arnfjörð Bjarmason
2022-03-01 6:38 ` Abhradeep Chakraborty [this message]
2022-03-01 11:12 ` Junio C Hamano
2022-03-01 19:37 ` Johannes Schindelin
2022-03-03 17:34 ` Abhradeep Chakraborty
2022-03-03 22:30 ` Junio C Hamano
2022-03-04 14:21 ` Abhradeep Chakraborty
2022-03-07 16:12 ` Johannes Schindelin
2022-03-08 5:44 ` Abhradeep Chakraborty
2022-03-01 20:08 ` [PATCH] parse-options: make parse_options_check() test-only Junio C Hamano
2022-03-01 21:57 ` Ævar Arnfjörð Bjarmason
2022-03-01 22:18 ` Junio C Hamano
2022-03-02 10:52 ` Ævar Arnfjörð Bjarmason
2022-03-02 18:59 ` Junio C Hamano
2022-03-02 19:17 ` Ævar Arnfjörð Bjarmason
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220301063801.26732-1-chakrabortyabhradeep79@gmail.com \
--to=chakrabortyabhradeep79@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).