Re: [WIP v3 0/7] mv: fix out-of-cone file/directory move logic

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 23, 2022, 16:19 UTC
Message-ID: <xmqqr13f1het.fsf@gitster.g>
In-Reply-To: <553ea547-9641-eb95-a474-db046fdc05dc@github.com>

Derrick Stolee <derrickstolee@github.com> writes:

Show 38 quoted lines

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