From: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Taylor Blau" <email@example.com>,
firstname.lastname@example.org, "Đoàn Trần Công Danh" <email@example.com>
Subject: Re: js/bisect-in-c (was: What's cooking in git.git (Oct 2022, #09; Mon, 31))
Date: Fri, 11 Nov 2022 15:11:56 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Thu, Nov 10 2022, Johannes Schindelin wrote:
> Hi Taylor,
> On Wed, 2 Nov 2022, Taylor Blau wrote:
>> On Wed, Nov 02, 2022 at 06:22:17PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> > On Mon, Oct 31 2022, Taylor Blau wrote:
>> > > What's cooking in git.git (Oct 2022, #09; Mon, 31)
>> > > --------------------------------------------------
>> > >
>> > > * js/bisect-in-c (2022-08-30) 17 commits
>> > > . bisect: no longer try to clean up left-over `.git/head-name` files
>> > > . bisect: remove Cogito-related code
>> > > . Turn `git bisect` into a full built-in
>> > > . bisect: move even the command-line parsing to `bisect--helper`
>> > > . bisect--helper: make `state` optional
>> > > . bisect--helper: calling `bisect_state()` without an argument is a bug
>> > > . bisect: avoid double-quoting when printing the failed command
>> > > . bisect run: fix the error message
>> > > . bisect: verify that a bogus option won't try to start a bisection
>> > > . bisect--helper: migrate to OPT_SUBCOMMAND()
>> > > . bisect--helper: make the order consistently `argc, argv`
>> > > . bisect--helper: make `terms` an explicit singleton
>> > > . bisect--helper: simplify exit code computation
>> > > . bisect--helper: really retire `--bisect-autostart`
>> > > . bisect--helper: really retire --bisect-next-check
>> > > . bisect--helper: retire the --no-log option
>> > > . Merge branch 'sg/parse-options-subcommand' into js/bisect-in-c
>> > >
>> > > Final bits of "git bisect.sh" have been rewritten in C.
>> > >
>> > > Needs review.
>> > > cf. <email@example.com>
>> > > source: <firstname.lastname@example.org>
>> > I see this has been ejected out of "seen", presumably due to the
>> > outstanding conflicts.
>> If I recall correctly, I ejected this one due to its age and lack of
>> attention. If you want to reroll it or if Johannes wants to take a look,
>> I'd be appreciative.
[Replying here instead of <email@example.com>,
but take this as a reply to that as well]
> My last information was that I sent an iteration that was designed to
> address all outstanding concerns, including a rather major haul to put
> this on top of the new `OPT_SUBCOMMAND` feature that wasn't even dreamed
> of when I sent v1 of `bisect-in-c`, and then I only saw "Needs review."
> for several weeks and nobody objecting but also in particular Ævar (who
> raised concerns against this patch series several times over the last 10
> months) not chiming in with a "go ahead".
I think that "go ahead" from me was pretty unambiguous in , i.e. I said:
"I think as it stands that it's a net improvement on "master". I
would not mind it advanced in its current state. We can fix any
outstanding issues with it later, particularly due to what seem
like time constraints on your end[...]"
> So basically, I thought this was finally done and the next thing I hear is
> that it is ejected. [...]
What you're eliding here is that on the 4th Lukáš Doktor reported a
regression in "git bisect" that pre-dated your cooking topic.
You didn't participate in that discussion, except now to say that you
weren't motivated to review parts of the proposed fixes for that
Which is relevant because in your topic you spend a lot of time
converting various code for the supposed needs of a migration to
OPT_SUBCOMMAND(). Just the diffstat for that was:
1 file changed, 128 insertions(+), 134 deletions(-)
Which didn't get all the way to the full OPT_SUBCOMMAND(). That still
needed  and , which are, respectively:
1 file changed, 14 insertions(+), 15 deletions(-)
2 files changed, 288 insertions(+), 194 deletions(-)
Whereas Đoàn's "dd/bisect-helper-subcommand", which is now in "next",
and which was aiming for the shortest route to fixing that regression,
and which also gave us OPT_SUBCOMMAND() is:
3 files changed, 142 insertions(+), 120 deletions(-)
This is all around 2 months after Junio's feedback on your latest
iteration was also questioning the need for that rewrite to get to the
goal of OPT_SUBCOMMAND().
> That's quite a frustrating experience, I must admit.
> At least I am not a new contributor who would be very much deterred from
> contributing any further by such an experience.
It's been frustrating for me too, particularly the as this isn't the
first time that I feel like you're outright misrepresenting something
I've said or done.
But I really don't think any of this translates to some general
unfriendliness on the list that new contributors would run into.
To take just the above example: New contributors aren't sending hundreds
of lines of patches to get to a stated goal of "X" by doing "A", and
then ignoring or dismissing reviews when it's pointed out to them that
they can get to "X" in a much easier manner by doing "B" instead.
Your original topic is a daunting:
7 files changed, 406 insertions(+), 388 deletions(-)
Which, as noted above the replacement of Đoàn's
3 files changed, 142 insertions(+), 120 deletions(-)
And his "dd/git-bisect-builtin" in seen is:
5 files changed, 77 insertions(+), 58 deletions(-)
Does that get us all the same thing sas js/bisect-in-c? No. But it does
get us to the primary goal whith fewer changes, which I think is the
main reason why your series has had such a hard time advancing.
next prev parent reply other threads:[~2022-11-11 14:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 5:31 What's cooking in git.git (Oct 2022, #09; Mon, 31) Taylor Blau
2022-10-31 23:44 ` ab/cmake-nix-and-ci (was: What's cooking in git.git (Oct 2022, #09; Mon, 31)) Ævar Arnfjörð Bjarmason
2022-10-31 23:45 ` ab/make-bin-wrappers " Ævar Arnfjörð Bjarmason
2022-10-31 23:46 ` ab/misc-hook-submodule-run-command " Ævar Arnfjörð Bjarmason
2022-11-01 0:15 ` Taylor Blau
2022-11-02 17:13 ` Ævar Arnfjörð Bjarmason
2022-11-02 17:24 ` Taylor Blau
2022-11-02 16:49 ` What's cooking in git.git (Oct 2022, #09; Mon, 31) Ramsay Jones
2022-11-02 17:22 ` js/bisect-in-c (was: What's cooking in git.git (Oct 2022, #09; Mon, 31)) Ævar Arnfjörð Bjarmason
2022-11-02 17:26 ` Taylor Blau
2022-11-10 13:35 ` Johannes Schindelin
2022-11-11 4:46 ` Taylor Blau
2022-11-11 14:11 ` Ævar Arnfjörð Bjarmason [this message]
2022-11-10 13:32 ` Johannes Schindelin
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:
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 \
* 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
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).