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

From: Johannes Sixt <j6t@kdbg.org>
Date: Nov 28, 2016, 21:25 UTC
Message-ID: <73836804-a581-85a4-b0c0-2aa46a7f9b8d@kdbg.org>
In-Reply-To: <xmqqshqbicga.fsf@gitster.mtv.corp.google.com>

Am 28.11.2016 um 21:20 schrieb Junio C Hamano:

Show 19 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?
>>
>> 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