Я не уверен, что это поведение причудливо, но вот что происходит: кажется, что если я запустил git blame в файле, любые строки в этом файле, которые являются исходными, имеют SHA с ведущей кареткой (^), как это
^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world! bbcd4a96 (Brian Danielak 2012-10-27 19:11:54 -0700 2) hello again!
В командной строке терминала:
mkdir newProject
cd newProject
git init
echo 'hello, world!' >> testFile.txt
git add testFile.txt
git commit -m "Initial Commit"
git blame testFile.txt
Затем убедитесь, что ваш результат вины имеет ведущую каретку, как и моя (хотя ваша SHA, вероятно, не будет соответствовать)
^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world!
В качестве теста вы можете попробовать добавить вторую строку в файл и переписать, чтобы увидеть, что только хэш первой строки содержит ведущую каретку
echo 'hello again!' >> testFile.txt
git add testFile.txt
git commit -m "Initial Commit"
git blame testFile.txt
Мой вывод вины теперь выглядит следующим образом:
^bb65026 (Brian Danielak 2012-10-27 19:11:54 -0700 1) hello, world! bbcd4a96 (Brian Danielak 2012-10-27 19:11:54 -0700 2) hello again!
Может ли кто-нибудь объяснить, почему это происходит, и должен ли я ожидать этого? Это происходит только тогда, когда строка берется из первого фиксации в репо? Если да, то почему?
В документах для git wame фактически упоминается, что каретка используется для "граничной фиксации", которая выглядит так, как будто они 'определяя что-то вроде "самой старой фиксации в этом диапазоне вины" - в вашем случае это первоначальная фиксация проекта, но с некоторыми различными параметрами, которые вы, возможно, только обвинили в совершении с 3 недель назад.
Я столкнулся с этой проблемой внезапно в очень старом репозитории и был смущен этим.
Проблема закончилась тем, что я каким-то образом получил мелкий клон в какой-то момент. Простой git fetch --unshallow исправил его.