4 ms·

One obvious requirement for bisect to work is that your code builds on every commit - and so does everybody else participating in the git history. Straw poll -

One obvious requirement for bisect to work is that your code builds on every commit - and so does everybody else participating in the git history. Straw poll - do you enforce this? If so, for literally every commit, or do you use partial squashing to maintain this property? While that's certainly a _desirable_ property, I've never really been concerned if, say, the penultimate commit on a PR failed CI. It feels like it would be a hassle.

alkonaut 6y ago
What (I assume) is normal is that you have PR validation and CI builds that only maintain the stable shared branches. If the validation isn't extremely fast (seconds or minutes) then maintaining it for every commit is almost impossible. It would just get other side effects like people avoiding commits because they don't want to run an hous-long test suite more than once.
yipbub 6y ago
I've always been careful about this even though I've not had the habit reward me yet (3 years of exp). If I'm rebasing, I go through every commit and make sure it builds. TIL about `git bisect` and it's really vindicating.
aeonflux 6y ago
There is no such requirement, you can just skip commits which cannot be tested. You just make a simple test-case just for current bug outside the repo.
speedgoose 6y ago
We use JavaScript at work so even if a part of the application doesn't compile, we usually can run most of the tests. We don't bisect very often and so far, every commit has been good enough for the specific tests we wanted to execute in case of a bisect.
chinigo 6y ago
I don't "enforce" this but I do aim for it, and yes, I do partial squashing throughout my workday. As I work on a feature branch, I'll check in WIP commits as checkpoints, especially at EOD. I don't expect these to pass the full CI suite. But as the code starts to shape up, I'll unstage all those WIPs and start to group the changes into logical commits. As work progresses, I'll use `git add --patch` to split new lines of code into those existing logical commits. Sometimes I'll split one up, sometimes I'll group two together; it's still flexible and amorphous at this point. By the time I'm ready to merge upstream, these commits tend to be neat, focused, and functional, and I do check to make sure they pass the relevant tests (though I don't enforce a full CI build here). Then a rebase from master, push to CI, and then a no-ff merge commit into master to retain both the low-level commits and the ability to easily revert the whole lot. It might seem like a ton of busywork, but I find that staging atomic commits like this doubles as an excellent line-by-line review of the code I've written. It also forces that review step to happen throughout the process rather than all the way at the end when I've forgotten all that deep context.

alkonaut 6y ago

What (I assume) is normal is that you have PR validation and CI builds that only maintain the stable shared branches. If the validation isn't extremely fast (seconds or minutes) then maintaining it for every commit is almost impossible. It would just get other side effects like people avoiding commits because they don't want to run an hous-long test suite more than once.

yipbub 6y ago

I've always been careful about this even though I've not had the habit reward me yet (3 years of exp). If I'm rebasing, I go through every commit and make sure it builds. TIL about `git bisect` and it's really vindicating.

aeonflux 6y ago

There is no such requirement, you can just skip commits which cannot be tested. You just make a simple test-case just for current bug outside the repo.

speedgoose 6y ago

We use JavaScript at work so even if a part of the application doesn't compile, we usually can run most of the tests. We don't bisect very often and so far, every commit has been good enough for the specific tests we wanted to execute in case of a bisect.

chinigo 6y ago

I don't "enforce" this but I do aim for it, and yes, I do partial squashing throughout my workday. As I work on a feature branch, I'll check in WIP commits as checkpoints, especially at EOD. I don't expect these to pass the full CI suite. But as the code starts to shape up, I'll unstage all those WIPs and start to group the changes into logical commits. As work progresses, I'll use `git add --patch` to split new lines of code into those existing logical commits. Sometimes I'll split one up, sometimes I'll group two together; it's still flexible and amorphous at this point. By the time I'm ready to merge upstream, these commits tend to be neat, focused, and functional, and I do check to make sure they pass the relevant tests (though I don't enforce a full CI build here). Then a rebase from master, push to CI, and then a no-ff merge commit into master to retain both the low-level commits and the ability to easily revert the whole lot. It might seem like a ton of busywork, but I find that staging atomic commits like this doubles as an excellent line-by-line review of the code I've written. It also forces that review step to happen throughout the process rather than all the way at the end when I've forgotten all that deep context.