Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > On Fri, Jun 03 2022, Junio C Hamano wrote: > >> Indeed it makes it impossible to figure it out things like this >> case. But ... >> >>> But this does look easy to "solve" with a quicker fix, just bringing >>> back the "ci/print-test-failures.sh" step so you can at least expand it, >>> and not have to go to the "summary" and download the *.zip of the log >>> itself. As that shows we still have the raw log there, it just didn't >>> make it to the new GitHub Markdown formatting mechanism. >> >> ... it seems a solution is possible? Care to send in a patch (or >> perhaps Dscho already has a counter-proposal)? > > The only thing I have at the moment is: > > 1. git revert -m 1 bd37e9e41f5 > 2. merge: https://lore.kernel.org/git/cover-v6-00.29-00000000000-20220525T094123Z-avarab@xxxxxxxxx/ > 3. merge: https://lore.kernel.org/git/cover-v6-00.14-00000000000-20220525T100743Z-avarab@xxxxxxxxx/ > > I.e. to pick this in the sequence I'd proposed doing & have tested > thoroughly. I know you two have difference in opinions, but throwing away everything the other party did and forcing your stuff in is not a very effective way to work together. > It also addresses other noted some other regressions in "next", but as > noted e.g. in [A] there's other issues in "next", e.g. that even the > "raw" trace logs are altered as a side-effect of running with > --github-workflow-markup, and of course the major UX slowdowns. Dscho? I know you do not care about the UX slowdown as much as others, but I am sure you do not consider what is in 'next' is perfect. It seems to need further work to go back to the feature parity with what it replaced.
