Hi, Junio C Hamano wrote: > So, perhaps there is something you are not quite telling us, > e.g. your problem happens during a replay an old bisect session > after HEAD has moved---if we had a bug that records symbolic object > names in the replay log, it may produce a nonsense result in such a > case (but I doubt that is the case---I am reasonably sure that the > log also records concrete object names)? > > Perhaps you can try again with a better minimum reproducible > example? Indeed, I was a bit naive to assume that bisect didn't rev-parse. I'm happy to report that I've found the minimum reproducible example. # on coq.git, for those curious $ git bisect start $ git bisect bad @ $ git bisect good V8.14.1 $ git bisect run bisect.sh # oops! Lancement de 'bisect.sh' 'bisect.sh': bisect.sh: command not found La base de fusion ea3595845f5013359b2ba4402f948e454350a74c est mauvaise. Cela signifie que le bogue été corrigé entre ea3595845f5013359b2ba4402f948e454350a74c et [2e100906d5d0c276335665ffefedb906d21165ca]. error: la bissection a échoué : 'git bisect--helper --bisect-state (null)' a retourné le code erreur -3 $ git bisect run ./bisect.sh # let's try again! # churn ... build ... test Cela signifie que le bogue été corrigé entre ea3595845f5013359b2ba4402f948e454350a74c et [2e100906d5d0c276335665ffefedb906d21165ca ea3595845f5013359b2ba4402f948e454350a74c]. error: la bissection a échoué : 'git bisect--helper --bisect-state (null)' a retourné le code erreur -3 In all three of my runs, there was never a straightforward non-erroring sequence of git-bisect invocations (although my terminal history is lost). Perhaps git-bisect can be hardened a bit, instead of needlessly punishing the user with a long build + test that doesn't lead anywhere? Warm regards, Ram
