Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jul 02 2021, Felipe Contreras wrote: > > > Ævar Arnfjörð Bjarmason wrote: > >> On Wed, Jun 30 2021, Felipe Contreras wrote: > >> > Ævar Arnfjörð Bjarmason wrote: > >> > >> >> 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 don't know about Junio, I do want to make git easier to hack for > >> > people that don't share my setup, but I would like to know what that > >> > setup is. > >> > >> I think all of this is covered in detail upthread. > > > > From [1] I understand some systems have a problem clobbering a binary > > that is being run. So if you are running a test that is using a binary > > that you are rebuilding at the same time, you get an error. > > > > OK. > > > > I still don't see why anyone would want to rebuild the binary in the > > middle of running tests. The result of the tests is only meaningful for > > a particular build. This is what I don't get. I get that you want to do > > this, what I don't get is *why*. > > This is mostly covered upthread & in the linked thread(s), but as > summary / elaboration: > > 1. Running the tests on some of these machines takes 30-45 minutes. A > common use-case is firing off a test run to see how bright the > dumpster fire is that day, noticing an early failure, and inspecting > it manually. > > Then while the rest of the full run is underway I'd like to > re-compile and e.g. add some printf debugging guarded by a getenv() > to some isolated code I'm poking, it's nice if the full test run > isn't invalidated by that. > > Keep in mind that it takes 30-45 minutes because it's *slooooooow*, > so "just use another workdir" isn't a viable option. I'm also going > to wait 10-20 minutes for another full recompile in that workdir > (and now the concurrent test run takes more than an hour). OK. If you are careful enough that makes sense. > 2. We have bugs in the test suite that e.g. leave orphaned git-daemon > background processes on these platforms. > > Yes that should be fixed, but fixing it is annoying when you can't > even recompile and run other (even more broken) tests due to the bug > you're trying to fix. Yeah, that's a separate issue. > 3. You're assuming that the only thing I might want to use the built > git for is the tests. Not really. > 4. I think you/Junio/Jeff (although maybe less so in Jeff's case) are > taking this axiom that thou shalt not recompile during tests as an > absolute. Just like in language I'm not a prescriptivist in workflows either. The fact that I don't recompile during tests doesn't mean I would presume to dictate to others what they should do. You know more about your setup than me. > I think you've also said something to the effect that the 3rd party tool > should be the thing doing the in-place-rename if needed, fair > enough. > > But claiming that it's both an external implementation detail (so it > could do an in-place rename, or not), and also maintaining that we can't > do in-place rename ourselves because doing so would enable bad thing XYZ > to happen (i.e. this concurrent test thing), seems like a case of > wanting to have your cake and eat it too. I never claimed we can't do in-place rename ourselves, I only said that I did not see the point. And to be clear the fact that I don't see it doesn't mean it isn't here. Now I see why you want this and I suppose for this particular case only it does make sense to do the renaming. But it still seems like a wart to me. If the build system supported out-of-tree builds there would be no need for us to do this manually in the Makefile, correct? But yeah, for now I suppose there's no better alternative. -- Felipe Contreras
