Re: [PATCH v2 00/11] git worktree (re)move

Nguyễn Thái Ngọc Duy  [off-list ref] 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.