On 6/24/2022 12:19 AM, Junio C Hamano wrote:
> Derrick Stolee <derrickstolee@xxxxxxxxxx> writes:
>
>> On 6/21/2022 7:30 PM, Victoria Dye wrote:
>>> Shaoxuan Yuan wrote:
>>>> But I think it worth discuss if we should implement in-cone to
>>>> out-of-cone move, since it will be nice (naturally) to have it
working.
>>>>
>>>> However, I noticed this from the mv man page:
>>>>
>>>> "In the second form, the last argument has to be an existing
directory;
>>>> the given sources will be moved into this directory."
>>>>
>>>> I think trying to move out-of-cone, the last argument has to be an
non-existent
>>>> directory? I'm a bit confused: should we update some of mv basic
logic to
>>>> accomplish this?
>>>>
>>>
>>> I suspect this requirement is related to the POSIX 'mv' [1] (and
>>> corresponding 'rename()', used in 'git mv'), which also requires
that the
>>> destination directory exists. I personally don't think this requirement
>>> needs to apply to 'git mv' at all, but note that changing the
behavior would
>>> require first creating the necessary directories before calling
'rename()'.
>>>
>>> As a more conservative solution, you could do the parent directory
creation
>>> *only* in the case of moving to a sparse contents-only directory (using
>>> something like the 'check_dir_in_index()' function you introduced to
>>> identify).
>>>
>>> I'm also interested in hearing what others have to say, especially
regarding
>>> historical context/use cases of 'git mv'.
>>>
>>> [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
>>
>> I wanted to reply here to maybe get more attention on this point.
>>
>> My personal opinion is that `git mv` should move to the location
requested,
>> even if it requires adding parent directories. Changing that
behavior might
>> need to come as its own topic, before doing the
in-cone-to-out-of-cone work.
>> Knowing if this behavior can change (or must stay the same) informs
how that
>> sparse case will work.
>
> When a particular checkout excludes directory, say, Documentation/,
> from its cone of interest, we may not have that directory in the
> working tree. In such a scenario, if you did
>
> $ git mv new.txt Documentation/technical/
>
> the index may not even know if "Documentation/" (which most likely
> is represented as a sparse "tree entry in the index") has the
> "technical" subdirectory in it, so it may have to expand it
> on-demand. I do not have an objection against making it easier for
> users to do this.
>
> As part of its implementation, you may have to do an equivalent of
> "mkdir -p Documentation/technical/" before you can even materialize
> the "new.txt" file in the directory. I do not think that breaks the
> parallel to POSIX "mv" in that case, as Documentation/technical/ is
> *NOT* really a destination directory that does not exist.
> Conceptually, the directory (and all the directories in the full
> tree) exists---it is just the sparse-checkout is hiding it from the
> view.
>
> A corollary to the above is what should happen when you did
>
> $ git mv new.txt Documentation/no-such-directory/
>
> i.e. you try to do a move that would fail even if you weren't using
> the sparse-checkout feature. I think that *SHOULD* fail, if we
> wanted to be parallel to what POSIX "mv" does.
>
> Thanks.
Agree.
Thanks & Regards,
Shaoxuan
