Jak mogę użyć git bisect, aby znaleźć pierwsze DOBRE zatwierdzenie?

Mam następujący problem:

• wersja masterdziała dobrze
• wersja ostatniego tagu przed master(powiedzmy last) ma błąd
• kolega potrzebuje poprawki do swojej lastpoprawki na ten błąd

W porządku. Zapytajmy naszego przyjaciela git bisecto wersję, która naprawiła błąd:

git bisect start
git bisect bad last
git bisect good master

Ale to nie zadziała:

Niektóre dobre obroty nie są przodkami złych obrotów.
git bisect nie może działać poprawnie w tym przypadku.
Może mylisz dobre i złe obroty?

Jakieś wskazówki, jak temu zaradzić? Czy przegapiłem coś w dokumentach?

Począwszy od git 2.7, możesz używać argumentów --term-old i --term-new.

Na przykład, możesz zidentyfikować zatwierdzenie naprawiające problem w ten sposób:

git bisect start --term-new=fixed --term-old=unfixed
git bisect fixed master
git bisect unfixed $some-old-sha1

Podczas testu powiedz git bisect fixedlub git bisect unfixedodpowiednio.

Stara odpowiedź dla wersji gita starszych niż 2.7

Zamiast tymczasowo uczyć się myśleć, że zło oznacza dobro, a dobro oznacza zło, dlaczego nie stworzyć aliasów?

Dodatkowo ~/.gitconfig:

[alias]
        bisect-fixed = bisect bad
        bisect-unfixed = bisect good

Możesz zacząć identyfikować zatwierdzenie naprawiające problemy w ten sposób:

$ git bisect start
$ git bisect-fixed master
$ git bisect-unfixed $some-old-sha1

Podczas testu powiedz git bisect-fixedlub git bisect-unfixedodpowiednio.

Po prostu „oszukiwałbym” gita i zamieniałbym znaczenie dobrego <=> złego.

Innymi słowy, traktuj „złą” jako coś, co nie powoduje problemu, więc nie jest to „dobra” wersja, na której można oprzeć twoją łatkę.

W każdym razie dobre i złe koncepcje są dość subiektywne, prawda? :)

git bisect start
git bisect good last
git bisect bad master

Jeśli używasz tak, git bisect runjak robiłem to z provepoleceniem Perla (który uruchamia testy automatyczne), nie masz możliwości po prostu zamienić goodi bad. Powodzenie testów zostanie zgłoszone jako kod zakończenia.

Znalazłem poprawną składnię Bash, aby zanegować kod zakończenia programu uruchamianego przez git bisect run:

git bisect start
git bisect bad HEAD                 # last revision known to PASS the tests
git bisect good $LAST_FAIL_REVISION # last revision known to FAIL the tests
git bisect run bash -c "! prove"

To dało mi pierwszą wersję, która przeszła testy prove.

Git teraz pozwala używać oldi newbez uprzedniego ich definiowania. Musisz wywołać git bisect startbez zatwierdzeń jako dalsze argumenty, a następnie poprawnie rozpocząć bisekcja przez wywołanie

git bisect old <rev>
git bisect new <rev>

https://git-scm.com/docs/git-bisect#_alternate_terms

Zasadniczo to, co sugerował @MarcH, powinno zostać wdrożone.

Aliasy Gita są dobrym pomysłem, jednak terminy fixedi unfixedmają ten sam problem co goodi bad: nie można ich mieć kompatybilnych zarówno z regresjami, jak i progresjami. Łatwo jest znaleźć słowa, które działają w obie strony: po prostu wybierz je z oryginalnej terminologii wyszukiwania binarnego, która ma charakter neutralny i nie ma z góry koncepcji, co jest dobre, a co złe. Na przykład:

git config --global alias.bisect-high 'bisect bad'
git config --global alias.bisect-low  'bisect good'

Dzięki neutralnym terminom, takim jak te, zawsze możesz wpisać: git bisect-high(lub git bisect-upper, lub git-bisect max... Twój wybór!), Czy szukasz regresji, czy poprawki .

Szkoda, że ​​programiści git bisect nie mogli po prostu ponownie użyć żadnego z istniejących terminów. Ogólnie rzecz biorąc, interfejs użytkownika nie jest problemem git: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/