> On 10/10/2023 12:39 AM GMT Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Is there a reason why somebody benefits by us retaining the current
> behaviour, where
>
> $ git mv file no/such/dir/yet/file
>
> fails with "No such file or directory", and they are forced to say
> either
>
> $ mkdir -p no/such/dir/yet
> $ git mv file no/such/dir/yet/file
>
> or
>
> $ git mv -p file no/such/dir/yet/file
Somewhat, as it could be a typo, so if you actually want to create a new folder, you have to be explicit. I wouldn't be opposed to removing the need for the flag, but if we did, I think we should warn the user that a new directory was created.
> Imagine there is no "no" directory (so nothing under it
> exists), and you did this (you do have a regular file "file").
>
> $ git mv [-p] file no/such/dir/yet
>
> What should happen? Would we do the equivalent of
>
> $ mkdir -p no/such/dir && git mv file no/such/dir/yet
>
> or are we doing
>
> $ mkdir -p no/such/dir/yet && git mv file no/such/dir/yet/file
>
> Both are plausible, and "mkdir -p" does not have such a nasty
> ambiguity. That is what makes me unsure about the new feature
> (again, either with required "-p" or with implied "-p").
I think the ambiguity is resolved by the inclusion of lack thereof of a trailing `/`. This is what the implementation already does, too, before this patch. So
$ git mv [-p] file no/such/dir/yet
would be the same as
$ mkdir -p no/such/dir && git mv file no/such/dir/yet
and
$ git mv [-p] file no/such/dir/yet/
would be the same as
$ mkdir -p no/such/dir/yet && git mv file no/such/dir/yet/
Moving `file` to `no/such/dir/yet/file`
Thanks for the feedback,
Hugo
P.S. Apologies for the duplicated email, Junio, I did a Reply instead of a Reply All
