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

[Junio C Hamano <gitster@pobox.com>]

Nguyễn Thái Ngọc Duy  <pclouds@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.