Sorry, me again, On Sat, 26 Oct 2019, Johannes Schindelin wrote: > 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 I should have mentioned that I also opened https://github.com/git-for-windows/git/pull/2373 with the same branch, which exercizes the Visual Studio build, too, so it is a bit more informative than the GitGitGadget PR (which only runs the regular GCC build on Windows which, as per Alex' analysis, is not affected by this problem). Ciao, Dscho > 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@xxxxxxxxxx/) 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 > > > 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 > > >
