On Thu, May 26, 2016 at 11:33:27PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > The only one I can think of is that if something leaves cruft in > > $TMPDIR, it could affect later tests that want to `git add` > > indiscriminately. > > Or "git ls-files -u", "git clean", etc. I'd mostly worry about a > failed test in which a program dies without a chance to clean up > after itself, and letting the cruft affecting the next test. Yeah, exactly. OTOH, that could be considered a feature. If one of our programs is leaving cruft in $TMPDIR, that is probably a bug that should be fixed. We wouldn't notice in most cases though (it would depend on some later test actually caring about the cruft). So your "leave cruft in the source directory but outside the trash directory" would be better there. I'd worry slightly that it would cause problems when running tests in parallel, though. Normal /tmp usage is OK with a global namespace (they choose unique names), but sometimes things might use /tmp with a well-known name as a rendezvous point (e.g, for sockets). But I guess such cases are already broken for running in parallel, since /tmp is a global namespace. > I just checked my /tmp, and I see a lot of directories whose name > look like mktemp generated one, with a single socket 's' in them. I > wouldn't be surprised if they turn out to be from our tests that > expect failure, killing a daemon that does not properly clean after > itself. People probably would not notice if they are in /tmp, and > if we moved TMPDIR to the trash, we still wouldn't (because running > tests successfully without "-d" option will remove the trash > directory at the end), but if it were dropped somewhere in the > source tree, we have a better chance of noticing it. Hmm. I'm not sure what would create a socket in git except the credential-cache stuff, and that does not write into /tmp (there was a GSoC-related series in March to move this, but I don't think it ever even made it to pu). Maybe the new watchman stuff? If you have inotify-tools, you can "inotifywait -m /tmp" and run "make test", but it's quite noisy, as apparently a lot of tested commands use tempfiles internally. Which perhaps shows that maybe some people would see a performance regression if we moved from /tmp to a slower filesystem (e.g., especially people whose git clone is on NFS or something). -Peff -- 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