Still unsolved: ensure your commits are not broken (aka pass all tests) without stashing everything else (in which case you could just as well stash the stuff you don't want in patch mode using `git stash -p`).
(even if they are in a feature branch, broken commits will break `git bisect` unless the branch is folded when merged)
Create commits using `add -p` up to the point that the current state of the work tree is fully committed. (You can `reset HEAD^` if you need to add some stuff that you do not want to become part of your branch's history, at least not in its current form.) Then test using run-command-on-git-revisions[1] on the new commits.
This lets you create multiple commits at the same time and run tests on all of them. You could argue that committing and resetting is effectively the same thing as stashing and popping, but I think the benefits of being able to iterate over a list of commits and test each one is worth creating additional commits that you will probably reset shortly after testing.
This is also what you should do after a rebase to test all affected commits as they have not neccesarily existed in a testable state in the work tree.
IIRC, you can clone the repo (leaving behind uncommitted changes) and run tests from that folder. Which also lets you run multiple tests in parallel if they're long, and continue to develop on your other branch, and ensures you have no absolute paths :) Cloning only takes a few seconds for even pretty large repos since it hardlinks everything.
Not necessarily. Use patch mode (or a tool like GitX that does the same job), commit, then stash and run your tests. If it's broken, amend your commit, rinse and repeat. Then push your changes or pop the stash and continue development.
I am not sure why you insist on not stashing the rest of your working directory ? This is a nice and non-permanent solution.
There's a difference between `stash -p` and `add -p + stash`, though. If you want to split your changes into more than two commits, you have to use add/commit/add/commit because stash will just make a commit with "what's left" (it's subtractive operation).
Skip means you can't run scripted bisects (such as `bisect run make test` or however that's spelled using your test runner) and either way when you reach a broken commit you have to determine whether it's broken due to what you're looking for or for some other reason, which means time wasted.
skip is necessary when your history is broken and fucked, but I'd just as well not have a broken and fucked history in the first place.
No, if your script exits with exit code 125, then that means "skip". You just need to write a wrapper script that'll handle that, so "make || exit 125 ; ./test-if-commit-is-good.sh" can do it.
(even if they are in a feature branch, broken commits will break `git bisect` unless the branch is folded when merged)