wie man halbiert, um eine gute commit von upsteam linux kernel zu finden?

Question

Ich benutze bisect, um den guten Commit zu finden, der ein S4-Problem von vorgelagerten Kernel-Codes behebt. Aber ich treffe ein verwirrendes Problem, wenn ich so tun:

git bisect start 
git bisect bad v4.8-rc1 
git bisect good v4.7 

es 13 Schritte unternehmen wird, um das Ergebnis zu beenden.

aber ich fand die Halbierung wird einige Commits älter als v4.7 Tag wählen, ist es normal?

Meiner Meinung nach sollte Halbierung Commits zwischen v4.7 Tag und v4.8-rc1 Tag aus der Zeitlinie zu beurteilen.

Answer 1

Meiner Meinung nach sollte Halbierung Commits zwischen v4.7-Tag und v4.8-rc1-Tag aus der Zeitlinie zu beurteilen.

Dies ist nicht genau das, was Halbierung tun wird. halbiert wählt alle Commits aus, die im Tag v4.8-rc1 enthalten sind und nicht im Tag v4.7 enthalten sind. Dies wird sich unterscheiden, wenn z.B. Ab v4.6 wird ein Zweig erstellt, und Änderungen werden vor dem Erstellen von v4.7 übernommen. Der Zweig wird jedoch nicht in v4.7 zusammengeführt. Insbesondere in der Kernel-Entwicklung kann es eine Menge Änderungen geben, die schon einige Zeit vor der Zusammenführung durchgeführt wurden. Das Datum dieser Commits liegt dann vor v4.7, jedoch sind ihre Änderungen nicht in v4.7 enthalten.

Es ist wichtig, dass sich bisect auf diese Weise verhält und nicht auf der Zeit basiert, wie es verwendet wird, um das Commit zu finden, das ein Problem einführte. Dies kann auch passieren, wenn ein Commit vor der "guten" Version erstellt wurde, aber noch nicht in dieser enthalten ist.

Wenn Sie ein Commit mit Ihnen haben, können Sie mit git tag --contains <commit-hash> überprüfen, in welchen Tags es enthalten ist. Höchstwahrscheinlich ist das Tag v4.7 nicht Teil dieser Liste und dies ist die Erklärung, warum diese Commits von git bisect gewählt werden.