Jeff King <peff@xxxxxxxx> writes: > Yeah, I can see the view that running the test suite as a basic sanity > check may have value, if it's backed by more careful testing later (and > certainly while I'm developing, I wouldn't hesitate to run a subset of > the test suite to see how my work is progressing). > > My main point was that I don't see much reason to do work to make that > kind of continuous "make test" work with simultaneous recompiles and > test-runs, if we can encourage people to do it more robustly with a > single compile-and-test-run loop. Maybe adding in the extra workdir > there makes it too heavy-weight? (Certainly my "ci" script is overkill, > but it seems like a loop of "reset to the current branch tip, compile, > run" in a worktree would be the minimal thing). I actually do use such a "runs tests in the background while I am not watching", so I am sympathetic to the higher-level goal, but I find any execution of the idea that requires "let's reduce the window where freshly built 'git' or any other things are not ready by forcing 'mv $@+ $@' trick for added atomicity" simply insane and not worth supporting. Tests are run to find cases where things go wrong, and it is a waste of cycles if that background task is not being run in isolation and on a stable state. A separate working tree is so easy to set up these days, I do not see a point in complicating the build procedure to avoid using it.
