On Mon, Jul 12, 2010 at 06:16, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi Ævar, > > Ævar Arnfjörð Bjarmason wrote: > >> Unless that's due to some unreproducable heisenbug you could get the >> trash directory by running the test with --debug. > > So what should I do after noticing a heisenbug? Run the test again with --debug. The test library and the commands it's calling don't live in the same address space. A "heisenbug" will probably be just as reproducable with --debug and without --debug. >> These trash directories are explicitly temporary, and >> should be cleaned up as the shell exists. > > When tests learned to remove the trash directory in test_done in > v1.6.1-rc1~336^2~1 (Enable parallel tests, 2008-08-08), that was not > the rationale; it was rather to avoid too many trash directories > piling up. If a test exits by mistake with ‘exit’ or fails with ‘-i’, > the one or two scratch directories involved are still kept for > debugging. That's the original rationale, which is fair enough. I think the behavior should be to clean up temporary files when the test exits, not just when it's done executing. > So you can see why a person would be reluctant to change this for > aesthetic reasons only. The reason I want to change it is that as I'm hacking Git I often run the tests but kill them before they've completed, because if I'm e.g. testing the test library itself I'm content with having only 10 tests pass before I continue improving it. If I keep doing that (along with --jobs 20 and --shuffle) I'll eventually pile up ~200 MB of trash. That'll exceed the limits of my ramdisk and I'll have to grudgingly do rm -rf trash* again. But maybe people such as yourself depend on the current behavior with regards to SIGINT. I don't feel strongly about it, and having to remove trash is a minor annoyance. If it's being used it should be kept. I just assumed that it was an omission in the cleanup routines. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html