On Tue, Nov 29, 2016 at 4:25 AM, Johannes Sixt <j6t@xxxxxxxx> wrote: > Am 28.11.2016 um 21:20 schrieb Junio C Hamano: >> >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >>> Does this round address the issue raised in >>> >>> >>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox >>> >>> by Dscho? >>> >>> Even if you are not tracking a fifo, for example, your working tree >>> may have one created in t/trash* directory during testing, and >>> letting platform "cp -r" taking care of it (if that is possible---I >>> didn't look at the code that calls busybox copy to see if you are >>> doing something exotic or just blindly copying everything in the >>> directory) may turn out to be a more portable way to do this, and I >>> suspect that the cost of copying one whole-tree would dominate the >>> run_command() overhead. >> >> >> Please do not take the above as me saying "you must spawn the >> platform cp -r". > > > copy_dir_recursively is used in 'worktree move' when the move is across file > systems. My stance on it is to punt in this case. *I* would not trust Git, > or any other program that is not *specifically* made to copy a whole > directory structure, to get all cases right when a simple rename() is not > sufficent. This is why I did not write new copy code. The code was from busybox, probably battle tested for many years now. Of course bugs can slip in when I integrated it to git. > And, uh, oh, it does a remove_dir_recursively() after it has > finshed copying. No, Git is not a tool to move directories, thank you very > much! I guess you won't like my (unsent) patch for moving .git dir either ;-) which does make me nervous. The thing is, these operations require some more modification in .git. We can't ask the user to "move this directory yourself, then come back to me and I will fix up the rest in .git". First step "only support moving within the same filesystem" works for me. But I don't know how rename() works on Windows... -- Duy