Pull to refresh

Comments 12

А как оно работает со слияниями?

Оно найдет коммит, который входит в слияние?

Но это ненадежный показатель работы-неработы.

Или оно будет смотреть на коммиты слияний?

А потом уже как-то искать среди коммитов данного слияния.

То есть вопрос в том, как сортируются коммиты.

Как минимум, у 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, как раз вот чтобы руками ничего не гонять. Если до нее дело не доходит — то обычно не то, что бисект не нужен, а даже и в консоль идти не надо, проще пару-тройку коммитов в идешечке переключить.

К тому же в ide их можно повыбирать умнее, но все равно бинарно.

Я думаю это смелое предположение. Куча людей подходят к куче вещей бессистемно. Поиск бага вряд ли является исключением.

Просматривать свои коммиты в обратном порядке, это реальный пример квадратичного поиска. Сложность квадратичного поиска 0(n^2)

Откуда взялся квадрат? Это линейный поиск, а с бисектом - логарифмический.

Я думал автор имел в виду просмотр коммита + запуск тестов + накапливающуюся когнитивную сложность. Но гарантий дать не могу, это перевод.

Звучит странно, что такое в этом случае N? А при бинарном поиске тогда какая сложность?

N все еще количество коммитов. Просто если взять 15 коммитов и все вручную проверить, то на 5-ом начнешь уставать, а к 10-му совсем будешь фрустрирован 📉.

А если взять бинарный вариант, то знаешь что за 4 раза справишься 📈.

Я так себе объясняю идею автора.

В среднем все равно нужно будет проверить N / 2 коммитов, т.е. зависимость линейная, автор походу не разбирается в математике.

Мне как новичку не ткнули носом - а делать то мне с полученным комитом дальше? Ну нашли мы багованный комит - как узнать что собственно случилось то? А багованный ли он вообще? Почему бы не привести команду чтобы переместиться на один комит назад и один в перёд? Почему бы не привести команду которая покажет разницу между комтом где всё работает и где всё не работает? да и как теперь узнать какой комит вообще предыдущий? Я конечно понимаю что вы мня сейчас пошлёте в официальную документацию, изучть git diff, git log и т.д. но и про бисект я бы узнал от туда же если бы имел желание туда залезать.

bisect помогает точно определить коммит, изменения которого привели к багу. Дальше просто анализ диффа, зачем ходить вперед-назад не понятно. Обычно сложно как раз найти ЧТО сломало приложение, а не КАК.

Sign up to leave a comment.

Articles