Post History

I'm quite certain that rsync is not able to deduce that /path/to/src/folder_a/file_w on one side of the transfer is identical to /path/to/src/folder_c/file_w on the other side of the transfer.

**Therefore, rsync won't be able to handle such a move efficiently.** To stock rsync, it will appear as one file having been deleted and the other having been created.

There are basically two ways of handling this:

 * Independently make the same changes on both sides of the transfer. That's easy for a single file, or if you control both sides and can access them simultaneously; but that might not always be practical.
 * Use a tool better suited for such change detection.

For example, if the (in this case) source code is in a Git repository, you can use [`git mv`](https://git-scm.com/docs/git-mv) to rename the parent directory; this should allow the tooling to keep track of which file is which even after the rename. Other version control systems will likely have ways to do much the same thing.

Alternatively, you can use a tool such as [unison](https://github.com/bcpierce00/unison/blob/master/README.md), possibly in one-way mode, to synchronize changes. I can attest to that it generally successfully detects and handles renames without re-transferring the file, but it relies on a fairly hefty chunk of external metadata to do so efficiently, and generally wants to either do the initial transfer itself or start with two identical trees; using it to transfer such a change after it has already been made would probably be risky.