Re: [PATCH] git mv: do not keep slash in `git mv dir non-existing-dir/`

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 5, 2016, 15:52 UTC
Message-ID: <xmqqtwezxlf2.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <e0415c55e9bc651e7fa9f5f7717b4f6e44eb9ce1.1470407827.git.johannes.schindelin@gmx.de>

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

Show 14 quoted lines

> 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.