From: Johannes Sixt Date: Mon, 28 Nov 2016 21:25:54 GMT Subject: Re: [PATCH v2 00/11] git worktree (re)move Message-ID: <73836804-a581-85a4-b0c0-2aa46a7f9b8d@kdbg.org> In-Reply-To: Am 28.11.2016 um 21:20 schrieb Junio C Hamano: > Junio C Hamano 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. 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! -- Hannes