Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes: > v2 contains some style fix and adapts to the new get_worktrees() api > from nd/worktree-list-fixup (which means it can't be built without > that series). > > Nguyễn Thái Ngọc Duy (11): > copy.c: import copy_file() from busybox > copy.c: delete unused code in copy_file() > copy.c: convert bb_(p)error_msg to error(_errno) > copy.c: style fix > copy.c: convert copy_file() to copy_dir_recursively() > worktree.c: add validate_worktree() > worktree.c: add update_worktree_location() > worktree move: new command > worktree move: accept destination as directory > worktree move: refuse to move worktrees with submodules > worktree remove: new command > > Documentation/git-worktree.txt | 28 ++- > builtin/worktree.c | 181 ++++++++++++++++ > cache.h | 1 + > contrib/completion/git-completion.bash | 5 +- > copy.c | 369 > +++++++++++++++++++++++++++++++++ > t/t2028-worktree-move.sh | 56 +++++ > worktree.c | 84 ++++++++ > worktree.h | 11 + > 8 files changed, 724 insertions(+), 11 deletions(-)
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.
