On 10-04-2024 21:31, Junio C Hamano wrote:
Olliver Schinagl <oliver@xxxxxxxxxxx> writes:
See, the hook is named 'post-checkout' and thus, it runs after
checkout has been performed. So we are now on the 'broken' commit we
do not want to test, git should have skipped this already, and not
checked it out.
You are not the only user of this feature (by the way, do not call
this a "hook". It should be per "git bisect" session)
Yep, it is stored as part of the bisect session when invoked via as a CLI.
and others may need to actually inspect their working tree state before being
able to say "nah, I do not want to test this version, please give me
another one" by exiting with 125.
So your use of 'You' and 'others' is a bit confusing, if it's me, the
person, and 'others' the script itself. But yes, I fully agree with what
you are saying I think. Just 'please give me a nother one' could be done
in the script itself, or via exit 125 of course (where I totally get
that doing the 125 routine is much better).
That is why post-checkout is more
useful in general. Contrasted with that, a check that happens
before the checkout is useful only in a much narrower "I can tell by
looking only at the commit object name" use case, which I would not
be interested in seeing.
So that leaves me in the same lack of understanding :p
If we run something post checkout, `bisect_checkout()` has run, and git
bisect (the application) is (almost) done. The directory has been
'checked out' (as `bisect_checkout()` of course does `git checkout`
(unless `no_checkout` is used) The tree is of course in a bisect session.
So if a script runs, and does the 'please give me a nother commit'
thing, how would that work within `builtin/bisect.c` (or in `bisect.c`).
This is the part that would puzzle me. The command returns with 125,
then what? How can git 'go on and give you a nother one'. afaik the only
return codes from `bisect_next()` etc are BISECT_OK and BISECT_FAIL?
Olliver
Thanks.
