Как "w20> винить" в удаленном репозитории?

на моем сервере Я размещаю свои личные проекты git с удаленной стороны (с gitosis), и я создал веб-интерфейс для просмотра репозиториев (что-то вроде Github).

На удаленной стороне вам не разрешено делать много вещей, потому что отсутствует рабочее дерево, и это правильно: btw, для проводника репозитория, с несколькими командами, которые я могу сделать почти все.

За исключением git вины.

Я не могу узнать, как обвинить файл без рабочего дерева в репозитории на удаленной стороне. У вас есть идеи?

Ответы

Ответ 1

Следующее должно работать даже в голых репозиториях:

git blame <rev> -- <path>

например.

git blame master -- README.txt

Ответ 2

Я не могу найти, о чем говорят 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 вам больше не понадобится " -- ".

См. Коммит 0c668f5 (05 февраля 2018 г.) Джунио С. Хамано (gitster).
(Объединено Junio C Hamano - gitster - в коммите 0c668f5, 07 февраля 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() хранилище, и нет никаких причин позволять 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 ", поэтому в той же ситуации он напечатал то же вводящее в заблуждение сообщение об ошибке, и этот патч также исправляет его.