On Mon, Jun 28 2021, Junio C Hamano wrote: > 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. Do you think upgrading git on your system without having to stop the world is worth supporting? Ultimately they're the same problem, and I had some patches in the works to make "make install" work like that, and wanted to eventually make the normal compilation use the same helper(s). Ensuring that tests don't fail either due to re-compilation is also a nice way to dogfood/smoketest if the installer is keeping that promise. > 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. Sure, at this point it's clear you won't take the patch. Just a note that this reply addresses 1/2 reasons I wanted this, i.e. not the AIX FS/behavior portability issue. > A separate working tree is so easy to set up these days,[...] I also test git on e.g. gcc farm boxes where I run out of disk space if I have a .git, a checkout directory with compiled files, and add a second checkout directory with compiled files, and on others where a compile/test cycle takes 30-40 minutes. If I had to do compilation twice things would slow to a crawl, and no, I'm not going to try to install ccache or whatever on some $OBSCURE_PLATFORM/$ANCIENT_OS/$ODD_TOOLCHAIN. > I do not see a point in complicating the build procedure to avoid > using it. I'd really understand your and Jeff's concerns if I was proposing some really complex workaround, but it's just extending & making consistent the "mv" dance we already use for 1/2 our rules already. Even if you don't care about the end result or making git easier to hack on for people who don't share your setup, I'd think that making those rules consistent across the board makes things less complex, not more. Anyway, let's not discussed this forever. We're clearly getting nowhere. Just for the record I'm quite miffed about the bar for "I don't care about this area/platform/use-case, but this person actively sending me patches in the area says it's helpful to send more patches" is so low. For comparison we have >1000 lines of CMake duplicating the entire Makefile now, all just to make things easier on Windows. It doesn't even work on *nix, so when the CI breaks because I updated the Makefile I need to push to some Windows box on GitHub and twiddle my thumbs hoping it'll pass this time around. Maybe that's all worth it, and I'd be willing to take the Windows devs at their word that dealing with the make dependency was really *that* painful. But compare that to carrying a few lines of "mv $@+ $@" to, I daresay, make the same or larger relative improvement on AIX. 1. https://lore.kernel.org/git/cover-0.6-00000000000-20210329T161723Z-avarab@xxxxxxxxx/
