Держать git пополам на пути предков

Question

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

У меня есть хороший коммит и плохой коммит, чтобы запустить пополам, где хороший коммит является предком плохого.

Я бы ожидал от git bisect до go коммитов, которые имеют хороший коммит в качестве предка, но это не так (использование git 2.21.0).

В настоящее время я делаю биссект вручную, сохраняя список коммитов и используя git rev-list --ancestry-path GOOD..BAD и выбирая коммит в середине. Есть ли способ автоматизировать это с git bisect? Есть ли у него флаг, чтобы остаться в пути предков?

Причины для деления пополам в пути предков

Функции, относящиеся к обнаруженной ошибке, могут существовать не во всех ветвях, поэтому проверить неактуально там. Однако они должны существовать в пути предков.

Как только разделение пути предков сделано, вероятно, в качестве вины будет получен коммит слияния, и они будут знать, что ошибка происходит из этой ветви. Это уже многому научит нас об ошибке.

Чтобы продолжить разбивать ветку, в которой была обнаружена ошибка, нужно протестировать не каждый коммит самостоятельно (поскольку они не обязательно имеют функции, необходимые для ошибка на поверхность), но нужно объединить каждый из них с последним хорошим коммитом и затем проверить, существует ли ошибка. Затем можно точно указать конкретный c коммит, который при слиянии с хорошим коммитом вносит ошибку.

Обратите внимание, что я проделал этот процесс несколько раз, и он был очень полезен для меня, и я ' Я просто ищу способы сделать его более удобным.

Answer 1

git bisect не имеет возможности следовать по пути предков. Такая опция обычно бесполезна по нескольким причинам:

• Чаще всего пользователи не знают наверняка, где была введена регрессия. Следовательно, сложные опции для управления обходом пути вряд ли будут использоваться.
• В большинстве случаев вы пропустите большое количество возможных ветвей, поскольку пропустите их. Если бы у вас было 1024 отдельных ветки с одним коммитом, слитым в вашу ветку master, git bisect пропустил бы половину из тех, которые даже не были рассмотрены после первого теста, и все равно потребовалось бы только двенадцать прогонов, чтобы найти проблемный c коммит .
• Часто проблемный коммит c находится в объединенной ветви и не находится на пути предка. Это верно для большинства случаев, когда у вас нет линейной истории (т. Е. Рабочих процессов, основанных на слиянии).

Если у вас нет специальных c знаний о вашем хранилище, таких как фиксация не в Путь предков будет давать ложные срабатывания или ложные отрицания, обычно хорошо просто позволить git rebase делать свое дело. Поскольку его поведение равно O (log N), дополнительные затраты, как правило, незначительны. Однако вы можете использовать git bisect skip RANGE, чтобы указать диапазон, который необходимо пропустить при необходимости.

Если вы можете автоматизировать тестирование вашей ветви с помощью сценария или команды оболочки, вы можете использовать git bisect run с этой оболочкой скрипт. Он должен выйти из 0, если фиксация хорошая, 125, если фиксация должна быть пропущена, и любой другой код от 1 до 127 включительно, если фиксация плохая. Это можно использовать, чтобы избежать проверки коммитов, которые по какой-либо причине не подходят.

Answer 2

Вы можете сделать это легко с существующим разделением вместо git bisect good agoodone do

git bisect good $(git rev-list \
        --ancestry-path --boundary agoodone..thebadone | sed -n s/-//p)