Re: [PATCH 0/3] Add `-p' option to `git-mv', inspired by `mkdir'

[Junio C Hamano <gitster@pobox.com>]

Hugo Sales <hugo@hsal.es> writes:

> Allow passing a new `-p'/`--parents' option to `git-mv' making it so
> missing directories in the given target path get created if they don't
> exist. This allows running `git mv -p foo bar/quux/' to first create
> the `bar/' and `bar/quux/' directories if they don't exist, and then
> move `foo' to `bar/quux/foo'.
>
> This is inspired by `mkdir -p foo/bar/quux/' which will create the
> `foo/', `foo/bar/', and `foo/bar/quux/' directories if they don't
> exist.

I'll step back and ask a related design question without reading the
patches (yet).

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

Yes, what I am getting at is if it makes sense to just "fix" the
behaviour of "git mv" about missing leading directories and do what
the end-user wanted to do without requiring "-p".

Regardless of the "do we require, or is it sifficient to imply, the
'-p' option when we lack leading directories?" question, once we
start "auto-creating" the leading directory hierarchy, one worrysome
thing such a new feature introduces is an ambiguity and unexpected
behaviour.  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").

Thanks.