(even if they are in a feature branch, broken commits will break `git bisect` unless the branch is folded when merged)
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.
[1] https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...
> without stashing everything else
and noted that if you're going to stash the rest either way you could just as well use `stash -p` in the first place.
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 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.