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

From: Duy Nguyen <pclouds@gmail.com>
Date: Nov 29, 2016, 12:08 UTC
Message-ID: <CACsJy8DQDPzZGJXLpTVHVFUeupPpp5e=b9z4m7xceJWrxPfF3Q@mail.gmail.com>
In-Reply-To: <xmqqshqbicga.fsf@gitster.mtv.corp.google.com>

On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Does this round address the issue raised in
>>
>>   http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>
>> by Dscho?

It does not (and is sort of expected), quoting from the commit message

    copy.c: convert copy_file() to copy_dir_recursively()

    This finally enables busybox's copy_file() code under a new name
    (because "copy_file" is already taken in Git code base). Because this
    comes from busybox, POSIXy (or even Linuxy) behavior is expected. More
    changes may be needed for Windows support.

I could "#ifdef WINDOWS return -ENOSYS" for now, which would make it build. "git worktree move" won't work on Windows of course...

Show 11 quoted lines

>> 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".

For the the record this was my first move but it will make it much harder to handle errors, and there's no native "cp" on Windows.

-- 
Duy