On Mon, Jul 23, 2018 at 12:14 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > To prevent such false positives from unnecessarily costing time when > > investigating test failures, let's take the exact order of the lines out > > of the equation by sorting them before comparing them. > > ... > > cat <<EOF >expect2 > > +Cloning into '$pwd/recursivesuper/super/merging'... > > +Cloning into '$pwd/recursivesuper/super/none'... > > +Cloning into '$pwd/recursivesuper/super/rebasing'... > > +Cloning into '$pwd/recursivesuper/super/submodule'... > > Submodule 'merging' ($pwd/merging) registered for path '../super/merging' > > Submodule 'none' ($pwd/none) registered for path '../super/none' > > Submodule 'rebasing' ($pwd/rebasing) registered for path '../super/rebasing' > > Submodule 'submodule' ($pwd/submodule) registered for path '../super/submodule' > > Thanks. It obviously goes in the right direction to loosen the > ordering requirement that fundamentally cannot be met, as the log > message cleanly analizes. > > Do we know that the write(2)s that show these lines are atomic, or > are we merely lucky that we don't see them intermixed in the middle > of lines (sbeller cc'ed). I _think_ they are but just wanted to > double check. Not just the lines, but the whole message per submodule (i.e. the "Cloning... " lione and its accompanying "done") is one atomic unit. These messages are from processes invoked via run_processes_parallel (in run-command.h), which buffers all output per process. This test was last touched in c66410ed32a (submodule init: redirect stdout to stderr, 2016-05-02), merged as f2c96ceb57a (Merge branch 'sb/submodule-init', 2016-05-17) The parallelizing effort was made before that (2335b870fa7 (submodule update: expose parallelism to the user, 2016-02-29) via bdebbeb3346 (Merge branch 'sb/submodule-parallel-update', 2016-04-06)), but did not review existing tests for the newly introduced raciness. Thanks for the fix! Stefan
