Comment pourrais-je utiliser git bisect pour trouver le premier bon commit?

J'ai le problème suivant:

• la version masterfonctionne bien
• la version de la dernière balise avant master(disons last) a un bogue
• un collègue a besoin d'un correctif pour sa lastrévision pour ce bogue précis

D'accord. Demandons à notre ami git bisectla révision qui a corrigé le bogue:

git bisect start
git bisect bad last
git bisect good master

Mais cela ne fonctionnera pas:

Certains bons régimes ne sont pas les ancêtres des mauvais régimes.
git bisect ne peut pas fonctionner correctement dans ce cas.
Peut-être confondez-vous les bons et les mauvais régimes?

Des conseils pour surmonter cela? Ai-je manqué quelque chose dans la documentation?

Depuis git 2.7, vous pouvez utiliser les arguments --term-old et --term-new.

Par exemple, vous pouvez identifier un commit de résolution de problèmes ainsi:

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

Au fur et à mesure que vous testez, dites git bisect fixedou git bisect unfixedselon le cas.

Ancienne réponse, pour les versions de git antérieures à 2.7

Au lieu de vous entraîner temporairement à penser que mauvais signifie bon et bon signifie mauvais, pourquoi ne pas créer des alias?

En ~/.gitconfigajouter ce qui suit:

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

Vous pouvez commencer à identifier un commit de résolution de problèmes ainsi:

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

Au fur et à mesure que vous testez, dites git bisect-fixedou git bisect-unfixedselon le cas.

Je "tricherais" simplement et j'échangerais les significations du bon <=> mauvais.

En d'autres termes, considérez «mauvaise» comme quelque chose qui ne présente pas le problème, donc ce n'est pas la «bonne» version sur laquelle baser votre patch.

De toute façon, le bien et le mal sont des concepts assez subjectifs, non? :)

git bisect start
git bisect good last
git bisect bad master

Si vous utilisez git bisect runcomme je l'ai fait avec la provecommande de Perl (qui exécute des tests automatiques), vous n'avez aucune chance de simplement échanger goodet bad. Le succès des tests sera signalé comme code de sortie.

J'ai trouvé une syntaxe Bash valide pour annuler le code de sortie du programme exécuté par 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"

Cela m'a donné la première révision pour réussir les tests effectués prove.

Git vous permet maintenant de les utiliser oldet newsans les définir au préalable. Vous devez appeler git bisect startsans commits comme arguments supplémentaires, puis démarrer correctement la bissection en appelant

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

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

C'est essentiellement ce que @MarcH suggérait de mettre en œuvre.

Les alias Git sont une bonne idée, mais les termes fixedet unfixedont le même problème que goodet bad: vous ne pouvez pas les rendre compatibles avec les régressions et les progressions. Il est facile de trouver des mots qui fonctionnent dans les deux sens: il suffit de les sélectionner dans la terminologie de recherche binaire originale qui est de nature neutre sans préjugé de ce qui est bon ou mauvais. Par exemple:

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

Avec des termes neutres comme ceux-ci, vous pouvez toujours taper: git bisect-high(ou git bisect-upper, ou git-bisect max, ... votre choix!) Si vous recherchez une régression ou une correction .

Dommage que les développeurs de git bisect ne puissent pas simplement réutiliser l'un des termes existants. L'interface utilisateur n'est pas la préoccupation de git en général: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/