Я не могу найти, о чем говорят git docs - опция, кстати, это работает очень
На самом деле это необходимо, потому что "git blame"готов принять древний нечетный порядок аргументов "blame <path> <rev>" в дополнение к обычному "blame [<rev>] <path>".
Это означает, что Git 2.17 (Q2 2018) объяснит "git blame HEAD COPYING" в простом видехранилище не удалось запустить, в то время как "git blame HEAD -- COPYING" работает нормально.
Но начиная с версии 2.17 вам больше не понадобится --.
См. commit 0c668f5 (05 февраля 2018 г.) Junio C Hamano (gitster) .
(Объединено с Junio C Hamano - gitster - in commit 0c668f5 , 07.02 2018)
blame: усилить синтаксический анализатор командной строки
Древний нечетный порядок аргументов "blame <path> <rev>" вдополнение к обычному «blame [<rev>] <path>» имеет по крайней мере два отрицательных значения:
Чтобы разделить эти два элемента, он проверяет, называет ли последний аргумент командной строки путь в рабочемдерево, используя file_exists().
Однако "blame <rev> <path>" - это запрос для объяснения каждой строки в содержимом <path>, хранящейся в ревизии <rev>, и не требует наличия версии файла в рабочем дереве.Проверка с file_exists() просто неправильна.
Чтобы принудить эту ошибочную file_exists() проверку к работе, код вызывает setup_work_tree() перед тем, как сделать это, потому что путь к ней относительнона верхний уровень дерева проекта.
Тем не менее, «blame <rev> <path>» ДОЛЖЕН использоваться даже в пустом хранилище, и нет никаких оснований для того, чтобы setup_work_tree() жаловался и умирал с «Эта операция должна быть запущена врабочее дерево ".
Чтобы исправить первый, переключитесь, чтобы проверить, является ли последний токен ревизией (и, если это так, проанализируйте аргументы, используя правило" blame <path> <rev> ").
Исправьте последнее, избавившись от проверок setup_work_tree() и file_exists() - единственный случай, когда вызов этой функции имеет значение, - это когда мы запускаем "blame <path>" (то есть не начинаем ревизию и просимобвините файл рабочего дерева в <path>, копаясь в ревизии HEAD), но в setup_scoreboard() есть вызов перед тем, как он вызывает fake_working_tree_commit().
Короче говоря, начинаяGit 2.17, это будет работать в обычном репо:
git blame master -- README.txt
А в Git 2.22 сообщение об ошибке "This operation must be run in a work tree" должно исчезнуть!
"git blame -- path"в не пустом хранилище начинает обвинять из рабочего дерева, и та же самая команда в пустом хранилище выдает ошибку, потому что по определению нет рабочего дерева.
Команда научилась вместо этого начинать обвинять с фиксации в HEAD,что более полезно.
См. коммит a544fb0 (07 апреля 2019 г.) SZEDER Gábor (szeder) .
(объединено Junio C Hamano - gitster - в коммит d8620d3 , 25 апреля 2019 г.)
blame: по умолчанию HEAD в голом репо, когда не предоставляется начальная фиксация
Когда 'git blame' вызывается без указания коммита, с которого начинается обвинение,он начинается с состояния данного файла в рабочем дереве.
Однако, когда он вызывается в пустом репозитории без начальной фиксации, состояние рабочего дерева отсутствует, и он умирает со следующим сообщением об ошибке:
$ git rev-parse --is-bare-repository
true
$ git blame file.c
fatal: this operation must be run in a work tree
Это вводит в заблуждение, потому что это подразумевает, что 'git blame' вообще не работает в голых репозиториях, но, на самом деле, работает нормально, когда ему дают коммит для запуска.
Конечно, мы могли бы улучшить сообщение об ошибке, но давайте вместо этого просто по умолчанию установим HEAD в пустом репозитории, поскольку, скорее всего, именно этого и хотел пользователь (если он хочет начать с другого коммита,они указали бы это в первую очередь).
'git annotate' - просто тонкая обертка вокруг 'git blame', поэтому в той же ситуации он напечатал тот же вводящий в заблуждение сообщением об ошибкеи этот патч тоже исправляет.