Comments 14
А как оно работает со слияниями?
Оно найдет коммит, который входит в слияние?
Но это ненадежный показатель работы-неработы.
Или оно будет смотреть на коммиты слияний?
А потом уже как-то искать среди коммитов данного слияния.
То есть вопрос в том, как сортируются коммиты.
Как минимум, у bisect есть опции:
--first-parent
Follow only the first parent commit upon seeing a merge commit.
In detecting regressions introduced through the merging of a branch, the merge commit will be identified as introduction of the bug and its ancestors will be ignored.
This option is particularly useful in avoiding false positives when a merged branch contained broken or non-buildable commits, but the merge itself was OK.
Все это намного быстрее чем проверять каждый коммит и искать иголку в стоге сена!
Никто в здравом уме не будет проверять каждый, деление пополам еще в школе же проходят.
Как по мне, весь смысл существования бисекта исключительно в опции run, как раз вот чтобы руками ничего не гонять. Если до нее дело не доходит — то обычно не то, что бисект не нужен, а даже и в консоль идти не надо, проще пару-тройку коммитов в идешечке переключить.
Просматривать свои коммиты в обратном порядке, это реальный пример квадратичного поиска. Сложность квадратичного поиска 0(n^2)
Откуда взялся квадрат? Это линейный поиск, а с бисектом - логарифмический.
Я думал автор имел в виду просмотр коммита + запуск тестов + накапливающуюся когнитивную сложность. Но гарантий дать не могу, это перевод.
Звучит странно, что такое в этом случае N? А при бинарном поиске тогда какая сложность?
N все еще количество коммитов. Просто если взять 15 коммитов и все вручную проверить, то на 5-ом начнешь уставать, а к 10-му совсем будешь фрустрирован ?.
А если взять бинарный вариант, то знаешь что за 4 раза справишься ?.
Я так себе объясняю идею автора.
В среднем все равно нужно будет проверить N / 2 коммитов, т.е. зависимость линейная, автор походу не разбирается в математике.
Мне как новичку не ткнули носом - а делать то мне с полученным комитом дальше? Ну нашли мы багованный комит - как узнать что собственно случилось то? А багованный ли он вообще? Почему бы не привести команду чтобы переместиться на один комит назад и один в перёд? Почему бы не привести команду которая покажет разницу между комтом где всё работает и где всё не работает? да и как теперь узнать какой комит вообще предыдущий? Я конечно понимаю что вы мня сейчас пошлёте в официальную документацию, изучть git diff, git log и т.д. но и про бисект я бы узнал от туда же если бы имел желание туда залезать.
git bisect: путешествие по времени и багам