In che modo git bisect salta scegliere il prossimo commit da provare?

Question

Quando si utilizza git bisect, è possibile eseguire git bisect skip per contrassegnare il commit corrente come non gestibile/non testabile, per provare a ottenere Git per selezionare altri commit da testare.

In che modo Git decide quale commit provare dopo lo git bisect skip? La sperimentazione mostra che non è solo un commit adiacente, ma non riesco a capire il modello.

Edit: Sono a conoscenza di base git bisect è una ricerca binaria, ma io sono curioso di sapere git bisect skip, che è chiaramente facendo qualcosa di più complicato.

La sperimentazione mostra che non si tratta solo di prelevare un commit adiacente; il sotto crea 100 commit numerati 0 – 99 quindi inizia a bisetterli. I primi commit git bisect sono nel mezzo, ma ogni git bisect skip sembra essere più o meno selezionato casualmente.

$ git init 
Initialized empty Git repository in .git/ 

$ for ((i=0; i<100; i++)); do echo $i > file; git add file; git commit -m $i >/dev/null; done # Create some dummy commits 

$ git bisect start HEAD $(git rev-list --max-parents=0 HEAD) # HEAD is bad, root commit is good. 
Bisecting: 49 revisions left to test after this (roughly 6 steps) 
[099e5cf2ccde625f92dc369da6cad0bdf2852ce4] 49 

$ git bisect skip 
Bisecting: 49 revisions left to test after this (roughly 6 steps) 
[88c8208a7c4322222124167e49f07c741af7d3d8] 60 

$ git bisect skip 
Bisecting: 49 revisions left to test after this (roughly 6 steps) 
[04695f2e5b2473c3ac72435c0dbfc3ba1375abda] 88 

$ git bisect skip 
Bisecting: 49 revisions left to test after this (roughly 6 steps) 
[1e9bf3d29589bcac2d8c467245ae8d446c195252] 40 

$ git bisect skip 
Bisecting: 49 revisions left to test after this (roughly 6 steps) 
[9459ed79e4112d674681c8f0f921127217c7ebc6] 13 

Answer 1

ho fatto un po 'scavare nel codice sorgente di Git e ha trovato la maggior parte di una risposta me stesso ...

partire dal Git v1.6.4 (in particolare, a partire da commit ebc9529f), Git utilizza "un PRNG (generatore di numeri pseudo casuali) con un bias" per determinare quale commit tentare dopo averne saltato uno.

Non posso dire che io seguo lo stesso algoritmo (che sembra essere fondamentalmente intatto da quando è stato aggiunto prima come di v2.8.1), ma il messaggio di commit fa un lavoro ragionevole di spiegare quello che sta succedendo:

bisect: utilizzare un PRNG con una polarizzazione quando saltando distanti verificabile impegna

Utilizzando un PRNG (generatore di numeri pseudo casuali) con una polarizzazione dovrebbe essere migliore di alternare tra 3 rapporti fissi.

Nei repository con molti commit non testabili dovrebbe impedire di alternare tra aree in cui molti commit non sono testabili. La distorsione dovrebbe favorire i commit che possono fornire ulteriori informazioni, in modo che il processo di bisection non debba perdere molta efficienza.

HPA ha suggerito di utilizzare un PRNG e ha rilevato che il miglior bias è quello di aumentare il rapporto tra 0 e 1 dato dal PRNG alla potenza 1.5.

in modo che appaia come se Git prende il prossimo impegnano a provare a caso, ma la distribuzione casuale è stato scelto per (si spera) scegliere commit che danno più informazioni per la ricerca binaria e per evitare commit che potrebbero trovarsi in regioni di commit non testabili.

Answer 2

Come il nome Git suggerisce, la risposta breve è: E 'non del vostro businness.

L'idea alla base git bisect è che si specificano due punti finali e Git capire un commesso, in mezzo, che pensa è quello utile per l'obiettivo di ridurre il numero di test.

Come la documentazione dice che questo è solo una ricerca binaria, ma non specifica che tipo di algoritmo viene utilizzato

bisect Poi git raccoglie un commit tra questi due punti finali

Può non essere un semplice pick-the-middle-commit binary search, Git può impiegare qualsiasi algoritmo decisionale che vuole e non vuole che tu lo sappia in modo che tu non faccia assunzioni sul commit che verrà scelto su.

Quando si tratta di cambiare il raccolto commit ti dà due possibilità:

1. si sceglie manualmente la nuova commit. Ad esempio con git reset --hard.
2. Dite a Git di fare una nuova scelta, con git bisect skip.

In quest'ultimo caso, come quando si aggiornano i punti finali con good e bad, la decisione è presa dal Git, il modo in cui vuole.

---

Per curiosità ho fatto semplice repository singolo ramo e provato il comando git bisect skip.
La mia versione di Git ha raccolto il commit precedente.