Como eu poderia usar o git bisect para encontrar o primeiro BOM commit?

Eu tenho o seguinte problema:

• a versão masterfunciona bem
• a versão da última tag antes master(digamos last) de ter um bug
• um colega precisa de um patch para sua lastrevisão para aquele bug específico

OK. Vamos pedir ao nosso amigo git bisecta revisão que corrigiu o bug:

git bisect start
git bisect bad last
git bisect good master

Mas isso não vai funcionar:

Algumas rotações boas não são ancestrais das rotações ruins.
git bisect não pode funcionar corretamente neste caso.
Talvez você confunda rotações boas e ruins?

Alguma dica para superar isso? Eu perdi algo nos documentos?

No git 2.7, você pode usar os argumentos --term-old e --term-new.

Por exemplo, você pode identificar um commit de correção de problemas assim:

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

Ao testar, diga git bisect fixedou git bisect unfixedconforme apropriado.

Resposta antiga, para versões do git anteriores a 2.7

Em vez de treinar temporariamente para pensar que ruim significa bom e bom significa ruim, por que não criar alguns apelidos?

Em ~/.gitconfigadicionar o seguinte:

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

Você pode começar a identificar um commit de correção de problemas assim:

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

Ao testar, diga git bisect-fixedou git bisect-unfixedconforme apropriado.

Eu apenas "trapacearia" git e trocaria significados de bom <=> mau.

Em outras palavras, considere "ruim" como algo que não apresenta o problema, então esta não é a versão "boa" para basear seu patch.

Bom e ruim são conceitos bastante subjetivos de qualquer maneira, certo? :)

git bisect start
git bisect good last
git bisect bad master

Se você estiver usando git bisect runcomo tenho feito com o provecomando Perl (que executa testes automáticos), você não tem chance apenas de trocar goode bad. O sucesso dos testes será relatado como código de saída.

Encontrei uma sintaxe Bash válida para negar o código de saída do programa executado por 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"

Isso me deu a primeira revisão para passar nos testes executados prove.

Git agora permite que você os use olde newsem primeiro defini-los. Você tem que chamar git bisect startsem commits como argumentos adicionais, então iniciar corretamente a bissecção chamando

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

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

Isso é essencialmente o que @MarcH estava sugerindo que deveria ser implementado.

Aliases Git são uma boa idéia, no entanto os termos fixede unfixedtenho o mesmo problema que goode bad: você não pode tê-los ser compatível com ambas as regressões e progressões. É fácil encontrar palavras que funcionam de qualquer maneira: simplesmente escolha-as da terminologia de pesquisa binária original, que é neutra por natureza, sem preconceito do que é bom ou ruim. Por exemplo:

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

Com termos neutros como esses, você sempre pode digitar: git bisect-high(ou git bisect-upper, ou git-bisect max, ... sua escolha!) Se você está procurando uma regressão ou uma correção .

Uma pena que os desenvolvedores do git bisect não puderam simplesmente reutilizar qualquer um dos termos existentes. A preocupação da interface do usuário não é do git de um modo geral: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/