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. <xmqqv8pr8903.fsf@gitster.g> >> > > source: <pull.1132.v6.git.1661885419.gitgitgadget@xxxxxxxxx> >> > >> > 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 <s024qpqn-0roo-3rr2-nr4p-74p9296r6p02@xxxxxx>, 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 [1], 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[2]. 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 regression it[3]. 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()[4]. 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 [5] and [6], 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()[7]. > 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 "dd/bisect-helper-subcommand" is: 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. 1. https://lore.kernel.org/git/220819.86sfls6zhh.gmgdl@xxxxxxxxxxxxxxxxxxx/ 2. https://lore.kernel.org/git/1cb1c033-0525-7e62-8c09-81019bf26060@xxxxxxxxxx/ 3. https://lore.kernel.org/git/2477861r-9363-75sn-q415-o19206q70p90@xxxxxx/ 4. https://lore.kernel.org/git/92b3b116ef8f879192d9deb94d68b73e29d5dcd6.1661885419.git.gitgitgadget@xxxxxxxxx/ 5. https://lore.kernel.org/git/c9dc0281e38bf9bc0bce72de172b5dbadbcbb1f5.1661885419.git.gitgitgadget@xxxxxxxxx/ 6. https://lore.kernel.org/git/e97e187bbec93b47f35e3dd42b4831f1c1d8658d.1661885419.git.gitgitgadget@xxxxxxxxx/ 7. https://lore.kernel.org/git/xmqqmtblighr.fsf@gitster.g/
