Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Stop explicitly line-buffering standard output
This removes `stdbuf -oL`. I had added the `stdbuf -oL` along with some other changes, but it seems the most likely of any of them to be producing the numerous new failures reporting "error while loading shared libraries: C: cannot open shared object file" (treating `C:` as though it is itself the name of a DLL to load) such as: FAIL [ 0.028s] gix-filter::filter pipeline::convert_to_git::only_driver_means_streaming_is_possible --- STDOUT: gix-filter::filter pipeline::convert_to_git::only_driver_means_streaming_is_possible --- running 1 test test pipeline::convert_to_git::only_driver_means_streaming_is_possible ... FAILED failures: failures: pipeline::convert_to_git::only_driver_means_streaming_is_possible test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 47 filtered out; finished in 0.02s --- STDERR: gix-filter::filter pipeline::convert_to_git::only_driver_means_streaming_is_possible --- failed to extract 'tests\fixtures\generated-archives\pipeline_repos.tar': Ignoring archive at 'tests\fixtures\generated-archives\pipeline_repos.tar' as GIX_TEST_IGNORE_ARCHIVES is set. thread 'pipeline::convert_to_git::only_driver_means_streaming_is_possible' panicked at tests\tools\src\lib.rs:567:17: fixture script of "bash" "D:\\a\\gitoxide\\gitoxide\\gix-filter\\tests\\fixtures\\pipeline_repos.sh" failed: stdout: stderr: 0 [main] bash 547 C:\Program Files\Git\usr\bin\bash.exe: *** fatal error - error while loading shared libraries: C: cannot open shared object file: No such file or directory note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace There were about 700 such failures, with a total of 719 failing tests. Let's see if no longer running the `cargo nextest` command through `stdbuf` makes them go away.
- Loading branch information