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. Thanks, -Stolee
