Renaming path and then renaming it back to the original name deletes path rather than renaming it about git-filter-repo HOT 1 OPEN

This problem looks to be an example of "unexpected" behavior that can occur when the new name in --path-rename <old_name:new_name> already exists in the commit history.

In the above scenario, the path rename of f1 to f2 works as expected as f2 does not exist in the commit history at the time of the path rename. It simply replaces f1 with f2 in the second commit.

On the other hand, the path rename of f2 to f1 show "unexpected" behavior as f1 already exists in commits 3 and 4 at the time of the path rename. The path rename replaces f2 with f1 in the second commit, which then "collides" with the existing f1 in commits 3 and 4. In particular, the f1 delete in commit 4 causes f1 to be deleted.

@newren I'm not exactly sure what you intend to happen when the new name in --path-rename <old_name:new_name> already exists in the commit history, though I suspect that it is working "as designed". Because of the potential for unexpected behavior, would it be possible to have --path-rename issue a warning message if the new name already exists in the commit history? I would also suggest updating the --path-rename documentation in the user manual with a warning about possible unexpected behavior when new name already exists in the commit history.

from git-filter-repo.