Имейте в виду, что в истории Git переименования файлов не хранятся как "это было переименовано из X в Y". Вместо этого файл X существует в одной ревизии, а в следующей ревизии Y существует (а X нет). Например:
Revision | Files
---------+----------------------------------
HEAD^ | a.cpp x.cpp z.cpp
HEAD | a.cpp y.cpp z.cpp
На приведенной выше диаграмме каждая ревизия представляет собой строку, и каждая содержит три файла. Между двумя ревизиями x.cpp был переименован в y.cpp. Единственная информация, которую хранит репозиторий, - это содержимое каждой отдельной ревизии.
Когда Git (или другой инструмент, который читает Git-репозитории) просматривает вышеупомянутую историю, он замечает, что y.cpp - это новый файл в HEAD. Затем он смотрит на предыдущую ревизию, чтобы увидеть, существовал ли подобный файл. В случае прямого переименования файла, тогда да, файл с именем x.cpp с идентичным содержимым существовал в предыдущей ревизии (и больше не существует в текущей ревизии). Таким образом, новый файл отображается как переименование от x.cpp до y.cpp.
В случае переименования и изменения, Git просматривает файлы предыдущей ревизии, чтобы увидеть, не выглядит ли один файл близко к новому файлу (с точки зрения его содержимого). Вот тут и начинается эвристика. Если большинство строк одинаковы, то Git покажет его как переименование, но если будет достаточно измененных строк по сравнению с неизмененными, то Git просто скажет, что это выглядит как новый файл.
Чтобы ответить на ваш вопрос, лучший способ обработать переименования классов reharper - это просто сделать это и зафиксировать новые файлы. Git хранит старые и новые файлы в своем хранилище. Обнаружение переименования обрабатывается позже, в тот момент, когда вы фактически спрашиваете об истории. Вот почему такие команды, как git log имеют такие параметры, как --find-copies и --find-copies-harder.