Hugo Sales <hugo@xxxxxxx> 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.
