Johannes Schindelin <johannes.schinde...@gmx.de> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html