Wie führe ich git bisect nur bei Commits aus, die eine bestimmte Datei geändert haben? [duplicate]

Lesezeit: 4 Minuten

Ich habe einen Fehler, der vor langer Zeit eingeführt wurde, und das Testen darauf ist schmerzhaft. Ich vermute jedoch stark, dass Änderungen, die den Fehler eingeführt haben, in einer bestimmten Quellcodedatei aufgetreten sind.

Kann ich git bisect auf einer Teilmenge von Commits ausführen, die diese eine Datei geändert haben?

Benutzeravatar von silvio
silvio

Ja, du kannst. Im die Manpagefinden Sie diese Zeile:

git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]
      [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]

so danach --setzen Sie die Pfade der Dateien oder Verzeichnisse.

Zum Beispiel:

git bisect start -- arch/i386 include/asm-i386

  • Was ist “Bogen”?

    – Eduard

    9. Januar 2019 um 13:02 Uhr

  • ‘arch/i386’, ‘include/asm-i386’ und, denke ich, ‘or’ wären die Pfade, auf denen bisect arbeitet. Es spielt keine Rolle, was sie sind – Silvio verwendet sie nur als Beispiele. Vermutlich, basierend auf dem Kontext, ist „arch“ die „Architektur“ für einen Build, in diesem Fall i386: en.wikipedia.org/wiki/Intel_80386 Im Fall von silvio wird also die Bisect ausgeführt, weil es ein Problem mit den i386-Builds geben würde, die gefunden werden müssen.

    – Knickum

    19. Februar 2019 um 23:35 Uhr

Benutzeravatar von Jan Warchoł
Jan Warchol

Git bisect ermöglicht es Ihnen, das Testen eines Commits zu vermeiden (siehe „Vermeiden, ein Commit zu testen“ in der Manpage): Wenn Sie halbieren und git ein Commit für Sie zum Testen ausgewählt hat, können Sie seine Auswahl mit überschreiben git reset --hard <commit you want>.

Verwenden git logkönnen Sie den letzten Commit finden, der eine Datei (oder ein Unterverzeichnis) betraf – dies gibt ihren Hash zurück:

git log -1 --pretty=format:%H -- path_that_you_are_interested_in

Also jedes Mal git bisect Ihnen einen zu testenden Commit vorschlägt, sollten Sie diesen Befehl ausführen, um sicherzustellen, dass Sie nur die betroffenen Commits testen somepath:

git reset --hard $(git log -1 --pretty=format:%H -- somepath)

Jetzt gibt es noch eine Sache, um die wir uns kümmern müssen. Wenn es keine interessanten Commits gibt (d. h. keine Commits, die modifizieren somepath) zwischen dem zuletzt geprüften guten Commit und dem aktuell ausgewählten Commit git bisect, könnten wir in einer Schleife landen. Um dies zu vermeiden, sollten wir einen Bedingungssatz verwenden:

#!/bin/bash

last_good=$(git bisect log | tail -1 | sed 's/git bisect good //')
last_interesting=$(git log -1 --pretty=format:%H -- lily/)

if [ "$last_good" == "$last_interesting" ]; then
    # there are no commits modifying somepath between previously
    # tested and currently checked-out one, so it must be good
    git bisect good
else 
    git reset --hard $(git log -1 --pretty=format:%H -- somepath)
fi

  • Aktualisiert, um eine potenzielle Endlosschleife zu vermeiden.

    – Jan Warchol

    13. September 2013 um 13:46 Uhr

  • Warum nicht verwenden git bisect skip wenn Commit, das keine Änderungen an der verdächtigen Datei enthält, nicht als gut markiert wird?

    – Jakub Narębski

    13. September 2013 um 16:57 Uhr


  • Wäre das nicht langsamer? Mit meiner Lösung, auch wenn bisect einen Commit auswählt, der uns nicht interessiert, springen wir sofort zum nächsten “interessanten” Commit. OTOH, wenn es insgesamt 10000 Commits gibt, aber nur 10 davon eine Rolle spielen, verwenden Sie skip würde bedeuten, auf unserem Weg viele “uninteressante” Commits zu besuchen.

    – Jan Warchol

    13. September 2013 um 19:45 Uhr

Eine Technik besteht darin, einen temporären Zweig zu erstellen, der an einer bekanntermaßen guten Position beginnt, und einfach über alle zu kopieren [i.e. a script] die Commits, die diese Datei berühren, und führen dann eine Halbierung auf diesem temporären Zweig durch. Auf diese Weise überspringen Sie alle irrelevanten Commits.

Dies wurde etwa im letzten Monat auf der Git-Mailingliste diskutiert $gmane/232114. Die Diskussion hat keinen einfachen Weg gefunden, Commits ohne relevante Änderungen vorab zu überspringen (es wäre wahrscheinlich etwas, das nützlich wäre – wie sie sagen, Patches willkommen).

  • Aber Sie können normalerweise keinen Zweig bekommen, der enthält begeht nur das Ändern einer Datei und gleichzeitig funktioniert noch.

    – Jan Warchol

    13. September 2013 um 13:27 Uhr

  • Ich ging davon aus, dass alle Ihre Mainline-Commits zum Zeitpunkt des Commits „gut“ waren. Haben Sie einen Indikator dafür, welche Commits zum Zeitpunkt des Commits als „gut“ erachtet wurden? Ohne dies haben Sie ein echtes Problem beim Skripten eines Revision Walkers, der diejenigen auswählt, von denen angenommen wurde, dass sie für die Bisect gut sind, um gegen sie zu arbeiten.

    – Philipp Oakley

    13. September 2013 um 15:50 Uhr

1429310cookie-checkWie führe ich git bisect nur bei Commits aus, die eine bestimmte Datei geändert haben? [duplicate]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy