Почему git blame не следует переименованиям?

git blame тут следуйте переименованиям (как и git log если вы даете ему --follow). Проблема заключается в путь он следует за переименованиями, что является не очень тщательным взломом: когда он отступает по одному фиксации за раз (от каждого ребенка к каждому родителю), он делает diff-тот же самый вид diff, который вы можете сделать вручную с:

git diff -M SHA1^ SHA1

- и проверяет, не обнаружил ли этот diff переименование.¹

это все нормально, насколько это происходит, но это значит, что для git blame чтобы обнаружить переименование, (a) git diff -M должен быть в состоянии чтобы обнаружить его (к счастью, это так) и-вот что вызывает у вас проблемы-он должен шаг через переименовать.

например, предположим, что график фиксации выглядит примерно так:

A <-- B <-- ... Q <-- R <-- S <-- T

где каждая заглавная буква представляет собой совершить. Предположим далее, что файл был переименован в совершения R, так что в commits R через T у него есть имя newname в то время как в commits A через Q у него есть имя oldname.

если вы запустите git blame -- newname последовательность начинается с T, сравнивает S и T, сравнивает R и S, и сравнивает Q и R. , когда он сравнивает Q и R, git blame обнаруживает изменение имени и начинает искать oldname в совершает Q и раньше, поэтому, когда он сравнивает P и Q он сравнивает файлы oldname и oldname в этих двух коммитов.

если, с другой стороны, вы запустите git blame R^ -- newname (или git blame Q -- newname) так, что последовательность начинается с фиксации Q нет файла newname в этом фиксации, и нет переименования при сравнении P и Q и git blame просто сдается.

фокус в том, что если вы начинаете с фиксации, в которой файл имел предыдущее имя, вы должны дать git старое имя:

git blame R^ -- oldname

и потом все это снова работать.

¹на git diff документация, вы увидите, что есть контролирует как git diff обнаруживает переименовывает. The blame код немного изменяет это (и на самом деле делает два прохода, один с -M выключен и секунду с -M включил) и использует свои собственные (разные) -M опция для несколько разных целей, но в конечном итоге она использует то же самое код.

[редактировать чтобы добавить ответ на комментарий (не подходит как сам комментарий)]:

- это любой инструмент, который может показать мне переименования файлов, такие как: Git renames SHA date oldname->newname

не совсем, но git diff -M близко, и может быть достаточно близко.

я не уверен, что вы подразумеваете под "датой SHA" здесь, но git diff -M позволяет поставить два SHA-1s и сравнивает влево против вправо. Добавить --name-status чтобы получить только имена файлов и склонностей. Отсюда git diff -M --name-status HEAD oldsha1 мая сообщить, что конвертировать из HEAD to oldsha1, git считает, что вы должны Rename файл и сообщит старое имя как "новое" имя. Например, в самом репозитории git есть файл с именем Documentation/giteveryday.txt который раньше имел немного другое имя:

$ git diff -M --name-status HEAD 992cb206
M       .gitignore
M       .mailmap
[...snip...]
M       Documentation/diff-options.txt
R097    Documentation/giteveryday.txt   Documentation/everyday.txt
D       Documentation/everyday.txto
[...]

если это файл, о котором вы заботитесь,вы хорошо. Две проблемы здесь являются:

• поиск SHA1: где 992cb206 откуда? Если у вас уже есть SHA-1, это легко; если нет,git rev-list является инструментом поиска SHA1; прочитайте его документацию;
• и тот факт, что после серии переименований через каждую фиксацию по одной фиксации за раз, как git blame делает, может дать совершенно разные ответы, чем сравнивать столь поздно (HEAD) против гораздо более раннего коммита (992cb206 или любой другой). В этом случае выходит то же самое, но "индекс подобия" здесь составляет 97 из 100. Если бы он был изменен намного больше на некоторых промежуточных этапах, этот индекс сходства мог бы упасть ниже 50% ... однако, если сравнить редакцию просто мало после 992cb206 to 992cb206 (as git blame будет), возможно, индекс сходства между этими двумя файлами может быть выше.

что нужно (и хватает) для для реализации --follow, так что все команды что использовать git rev-list внутренне-т. е. большинство команд, которые работают более чем на одной ревизии-может сделать трюк. По пути, было бы неплохо, если бы он работал в другом направлении (в настоящее время --follow только новее-старше, т. е. отлично работает с git blame и работает нормально с git log до тех пор, пока вы не попросите старейшую историю сначала с --reverse).