Hi Junio,
On Sat, 16 Feb 2019, Junio C Hamano wrote:
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
>
> >> > The current condition of the code is (the generate_zero_bytes delete
> >> > was previously removed so can be ignored for the patch):
> >>
> >> Just to make sure I do not misunderstand, this result is with Max's patch
> >> but
> >> without the generate_zero_bytes stuff?
> >
> > Correct.
>
> Thanks for a quick response. I've been staring at b46221ff ("Merge
> branch 'rb/no-dev-zero-in-test'", 2019-02-13). IIUC, t5562 wouldn't
> have passed if it still fed http-backend from /dev/zero, no? The
> shell redirection would have failed, so we do need to keep that part
> of the change---i.e. in order to pass, we do need cc95bc20 ("t5562:
> replace /dev/zero with a pipe from generate_zero_bytes", 2019-02-09)
> and Max's "t5562: do not reuse output files", right?
>
> I have been wondering about the whole /dev/zero business. Although
> we have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
> must have been somewhat incomplete to help platforms that lack
> /dev/zero in the first place.
>
> We haven't heard from Dscho in European timezone,
Some bacteria redirected me to /dev/zero for a few days. That hung my
inbox.
> but I'm inclined to
>
> - keep b46221ff in 'master', not reverted.
> - apply Max's "t5562: do not reuse output files"
>
> to 'master' and hope that we can declare victory in this part of the
> code ;-). There may be fix-ups for other topics before -rc2 on top
> of that, though.
For the record, I did not set up that fully automated PR build & test at
https://github.com/gitgitgadget/git just so people would still wait for me
to run the test; a simple PR would have tested this without waiting for
me.
Anyway, in the meantime, I tested it, and Max' test seems to work:
https://dev.azure.com/git-for-windows/git/_build/results?buildId=31274
Ciao,
Dscho
> >> Thanks, all. Hopefully we can get this test failures behind us before
> >> -rc2;
> >> knock, knock...
> >
> > Once the fix is integrated and in the usual spots, I can verify
> > with haste. The full test cycle is now at 50 hours (argh), which I
> > will rerun in full at rc2, but this one is fast.
>
