Это не отслеживает их. В этом вся прелесть.
Git записывает только снимки всего дерева проекта: вот как все файлы выглядели до фиксации, а вот как они выглядят после. Как мы попали отсюда туда, Git не волнует.
Это позволяет писать интеллектуальные инструменты после , когда коммит уже произошел, для извлечения информации из этого коммита. Например, обнаружение переименования в Git выполняется путем сравнения всех удаленных файлов со всеми новыми файлами и сравнения попарных метрик подобия. Если показатель сходства больше, чем x, они считаются переименованными, если он находится между y и x (y < x), он считается переименованным + редактировать, и если он ниже y они считаются независимыми. Круто то, что вы, как «археолог коммитов», можете после факта указать, какими должны быть x и y. Это не будет работать, если коммит просто записал «этот файл является переименованием этого файла».
Обнаружение перемещенного содержимого работает аналогично: вы разбиваете каждый файл на части, вычисляете метрики сходства между всеми срезами и затем можете сделать вывод, что этот срез, который был удален здесь, и этот очень похожий срез, который был добавлен туда, на самом деле являются одним и тем же срезом это было перенесено отсюда туда.
Однако, как тонфа упомянул в своем ответе, это очень дорого, так что обычно это не делается. Но это может быть , и в этом все дело.
Кстати: это в значительной степени полная противоположность модели оперативного преобразования, используемой Google Wave, EtherPad, Gobby, SubEthaEdit, ACE и Co.