Johannes Schindelin [off-list ref] writes:
When calling `rename("dir", "non-existing-dir/")` on Linux, it silently
succeeds, stripping the trailing slash of the second argument.
This is all good and dandy but this behavior disagrees with the specs at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
that state clearly regarding the 2nd parameter (called `new`):
If the `new` argument does not resolve to an existing directory
entry for a file of type directory and the `new` argument
contains at least one non- <slash> character and ends with one
or more trailing <slash> characters after all symbolic links
have been processed, `rename()` shall fail.
I agree with all of the above. But
Of course, we would like `git mv dir non-existing-dir/` to succeed (and
rename the directory "dir" to "non-existing-dir").
I do not think I want that. When I say "mv A B/", I want it to fail
if I made a typo for B; the trailing slash after B is an explicit
statement "I expect B to exist and I want A to appear at B/A".
Current Git behaviour on Linux seems to allow "git mv dir no-such-dir/"
but "dir" is renamed to "no-such-dir", which fails two expectations,
and I think this is broken. If Windows port does not share this
breakage, that is a good thing. We should fix Git behaviour on Linux
instead, I would think.
Hi Junio,
On Fri, 5 Aug 2016, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
When calling `rename("dir", "non-existing-dir/")` on Linux, it silently
succeeds, stripping the trailing slash of the second argument.
This is all good and dandy but this behavior disagrees with the specs at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
that state clearly regarding the 2nd parameter (called `new`):
If the `new` argument does not resolve to an existing directory
entry for a file of type directory and the `new` argument
contains at least one non- <slash> character and ends with one
or more trailing <slash> characters after all symbolic links
have been processed, `rename()` shall fail.
I agree with all of the above. But
quoted
Of course, we would like `git mv dir non-existing-dir/` to succeed (and
rename the directory "dir" to "non-existing-dir").
I do not think I want that. When I say "mv A B/", I want it to fail
if I made a typo for B; the trailing slash after B is an explicit
statement "I expect B to exist and I want A to appear at B/A".
Please note that t7001 *specifically* tests for the opposite of what you
want, then ;-)
https://github.com/git/git/blob/v2.9.2/t/t7001-mv.sh#L79-L80
Current Git behaviour on Linux seems to allow "git mv dir no-such-dir/"
but "dir" is renamed to "no-such-dir", which fails two expectations,
and I think this is broken. If Windows port does not share this
breakage, that is a good thing. We should fix Git behaviour on Linux
instead, I would think.
To be precise, Git for Windows displays the same behavior as Git on Linux,
because rename("dir", "no-such-dir/") succeeds.
The breakage fixed by this here patch happens when running plain Linux Git
in "Bash on Windows" (i.e. Bash on Ubuntu on Windows, the new Linux
subsystem of Windows, allowing to run unmodified Linux binaries on Windows
without the need for a Virtual Machine).
Ciao,
Dscho