Elijah Newren <[email protected]> writes:
>> As a fix, this sorely wants something new in t/ directory.
>
> Well, then perhaps I was wrong to submit it independent of my
> directory rename series. As noted in the (very lengthy) extended
> commit message explanation, the assumption the previous code made just
> happened to work ...
Here is what I wrote in What's cooking draft (which automatically
gets copied to the merge log message and becomes part of release
notes when a topic graduates) for this thing. Am I on the right
track?
The code internal to the recursive merge strategy was not fully
prepared to see a path that is renamed to try overwriting another
path that is only different in case on case insensitive systems.
This does not matter in the current code, but will start to matter
once the rename detection logic starts taking hints from nearby
paths moving to some directory and moves a path that is otherwise
not changed along with them.
