When you all rebase, do you usually ensure that your commits build after each rebase conflict resolution? Or do you typically rebase as carefully as possible, but then only run a build once at the end? Do you change your strategy depending on the number of commits in the branch? Is there another alternative I haven't thought of?
there’s no expectation of intermediate commits building at all
when we bisect we bisect merge commits.
I sometimes will rebase into intermediate commits, but I agree with @nagisa that we generally don’t expect/force PR’s to preserve buildability. Sometimes the only benefit of fragmenting PR into commits is for reviewability alone
Thank you, that's helpful feedback!
One advantage of buildable commits is that you can more easily split out earlier parts of the PR
this can be useful for the PR author
(https://github.com/rust-lang/rust/pull/65324 is an example)
Outside of Rust world, yes, I default to ensuring that every commit builds, lints, and passes tests. When doing an interactive rebase, theres the
x command which allows you to run custom scripts like a test suite or linter.
I would muse that my way is the best way (right...) but that the rustc build times prevent me from doing the build / test steps. And the lack of consistently-applied rustfmt means I cannot easily script rustfmt. So I let the broken windows stay broken.
In my own Rust projects (and other languages) I do all the cleanliness. I wouldn't be surprised if I spend more noticeably time reorganizing my commits than most other people. My hope is that future me appreciates it.