Issue #144 was trickier than expected. When a Move happens (and as a consequence, the full class name changes/is renamed) together with another refactoring, RMiner returns, as the name of the class before the refactoring, the name of the class after the rename.
I could not find a rule. For example, if a Move happens together with a Extract Method, the Extract Method object has the class name of the class before the rename. However, if it's a Move + Extract Interface, the Extract Interface has the name of the class after the rename.
I had to do a good amount of workaround for that to work. First, I get a map of old -> new paths from Git. So that we can always use the old file name to retrieve the version of the class before the refactoring. Then, I get a map of renamed classes, so that we can also always use the old name of the class.
Issue #144 was trickier than expected. When a Move happens (and as a consequence, the full class name changes/is renamed) together with another refactoring, RMiner returns, as the name of the class before the refactoring, the name of the class after the rename.
I could not find a rule. For example, if a Move happens together with a Extract Method, the Extract Method object has the class name of the class before the rename. However, if it's a Move + Extract Interface, the Extract Interface has the name of the class after the rename.
(I opened an issue in RMiner to better understand this behaviour: https://github.com/tsantalis/RefactoringMiner/issues/90)
I had to do a good amount of workaround for that to work. First, I get a map of old -> new paths from Git. So that we can always use the old file name to retrieve the version of the class before the refactoring. Then, I get a map of renamed classes, so that we can also always use the old name of the class.
Toy projects tests are passing.