Почему git -bisect нужно запускать из каталога верхнего уровня рабочего дерева?

Ответ 1

Глядя на некоторые коммиты в проекте, я вижу его Марселем М. Кэри ([email protected])

Он говорит в фиксации (это примерно о git -pull, но я думаю, что это имеет значение)

"git pull" не работает, потому что оболочки POSIX имеют представление о текущей работе каталог, отличный от getcwd(). Оболочка хранит этот путь в PWD. В результате "cd../" можно интерпретировать по-разному в shell script, чем chdir ( "../" ) в программе на C. Оболочка интерпретирует "../", по существу отсекая последний компонент текстового пути из PWD, тогда как C chdir() следует за ссылкой ".." в текущем каталоге в файловой системе. Когда PWD является символической ссылкой, это разные направления. В результате команды Git C находят правильные рабочего дерева верхнего уровня и сценариев оболочки нет.

https://github.com/git/git/commit/08fc0608657ee91bc85276667804c36a93138c7d

SO Я бы сказал, что часть причины объясняется тем, что git -bisect - это оболочка script, которой нельзя доверять, чтобы самостоятельно найти полный уровень (при использовании символических ссылок).

Ответ 2

Процесс бисекции должен проверять различные версии вашего проекта. Если конкретная ревизия не содержит текущую папку, то текущая папка будет удалена.

В этом случае ваша оболочка может оказаться в папке, которая больше не находится в файловой системе! Git не сможет найти папку верхнего уровня .git, и поэтому процесс bisect не может продолжаться без вмешательства.

Демонстрация:

$ git rev-parse --show-toplevel
/path/to/project
$ mkdir tmp
$ cd tmp
$ rmdir ../tmp
$ git rev-parse --show-toplevel
fatal: Unable to read current working directory: No such file or directory

Конечно, эта же проблема может возникнуть при выполнении git checkout, и ее можно легко устранить после факта, например. с cd .. (willoller объясняет, почему это работает в оболочке, но не в git).

Но так как деактивация - это процесс, имеет смысл избежать этой ситуации, прежде чем мы начнем, особенно если мы хотим использовать автоматизацию, такую ​​как git bisect run.

Ответ 3

В результате команды Git C находят правильное рабочее дерево верхнего уровня, а сценарии оболочки - нет.

Итак, с Git 2.21 (февраль 2019 г.) git bisect продолжает переход от сценария оболочки к C.

См. Коммит 06f5608, коммит 450ebb7, коммит 129a6cf, коммит 4fbdbd5, коммит e3b1e3b, коммит 0f30233, коммит 5e82c3d (02 января 2019 г.) от Pranit Bauva (pranitbauva1997).
jeffhostetler: Рамсей Джонс (jeffhostetler) и Стефан Бейер (sbeyer).
^{(Объединено Junio C Hamano - gitster - в коммите 09a9c1f, 07 февраля 2019 г.)}

bisect - помощник: bisect_start оболочки bisect_start частично в C

bisect_start функцию оболочки bisect_start частично в C и добавьте подкоманду bisect-start в git bisect--helper чтобы вызвать ее из git-bisect.sh.

Последняя часть не конвертируется, потому что она вызывает другую функцию оболочки. bisect_start оболочки bisect_start будет завершена после bisect_next функции оболочки bisect_next в C.

Это еще не завершено, но побочным эффектом этой миграции будет возможность выполнить git bisect из подпапки.

Git 2.23 дополнительно улучшает это преобразование в C.
См. Коммит 7877ac3 (21 мая 2019 г.) Йоханнеса dscho (dscho).
^{(Объединено Junio C Hamano - gitster - в коммите 5b476dc, 17 июня 2019 г.)}