Re: [PATCH v2 1/1] vreportf: Fix interleaving issues, remove 4096 limitation
From: Johannes Schindelin <hidden>
Date: 2019-10-26 21:57:08
Hi Peff, On Sat, 26 Oct 2019, Johannes Schindelin wrote:
[...] I did open a GitGitGadget PR with my proposed change,
I should have mentioned the URL: https://github.com/gitgitgadget/git/pull/428 FWIW, in the meantime I managed to address below-mentioned breakages (apart from the broken pipe problem that is discussed over here: https://public-inbox.org/git/20190828161552.GE8571@szeder.dev/) and the build is green. Alex asked to be given time to brush his patch up on Monday, so I am holding off sending my version (for now...). Ciao, Dscho
quoted hunk ↗ jump to hunk
in the hopes that I could somehow fast-track this fix into the CI/PR builds over at https://github.com/gitgitgadget/git, but there are problems: it seems that now there is an at least occasional broken pipe in the same test when run on macOS. There _also_ seems to be something spooky going on in t3510.12 and .13, where the expected output differs from the actual output only by a re-ordering of the lines: -- snip -- [...]+++ diff -u expect advice --- expect 2019-10-25 22:17:44.982884700 +0000 +++ advice 2019-10-25 22:17:45.278884500 +0000@@ -1,3 +1,3 @@ error: cherry-pick is already in progress -hint: try "git cherry-pick (--continue | --skip | --abort | --quit)" fatal: cherry-pick failed +hint: try "git cherry-pick (--continue | --skip | --abort | --quit)" -- snap --For details, see: https://dev.azure.com/gitgitgadget/git/_build/results?buildId=19336&view=ms.vss-test-web.build-test-results-tab and https://dev.azure.com/Git-for-Windows/git/_build/results?buildId=44549&view=ms.vss-test-web.build-test-results-tab (You need to click on a test case title to open the logs, then inspect the Attachments to get to the full trace) So much as I would love to see the flakiness of t5516 be fixed as soon as possible, I fear we will have to look at the underlying issue a bit closer: there are two processes writing to `stderr` concurrently. I don't know whether there would be a good way for the `stderr` of the `upload-pack` process to be consumed by the `fetch` process, and to be printed by the latter. Ciao, Dscho