Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> A .git/tmp/ would make housekeeping easier, you would know that every >> file under .git >> should be there and if you find something you don't recognize you would >> react. > > No, it would actually make it harder. I seem to recall that there was > some problem with renaming a file unless it was already in the same > directory as the destination. If all files were to be written to > .git/tmp/ first...
I agree with you here. This "some filesystems do not like cross-directory renames" was also why I thought the idea to create everything in $GIT_DIR/tmp and moving to the final destination would not fly well. For the specific issue with the shallow-cutoff list temporarily created, however, it is created, written to, read from and removed without ever leaving the original place, so we could designate one writable "temporary" place somewhere under $GIT_DIR, and $GIT_DIR/tmp could certainly that designated temporary place. By the way, the temporary shallow-cutoff-list is created by callingy xmks_tempfile(). I wonder if it can safely changed to use mks_tempfile() instead. That way, people can set up a wrapper for receive-pack that sets up a suitable TMPDIR exported to the real thing to relocate it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
