3 ms·

I don't see why you would bisect in this situation in the first place. The problem's fixed now, as of commit 5. But okay, let's take your example as-is: you de

I don't see why you would bisect in this situation in the first place. The problem's fixed now, as of commit 5. But okay, let's take your example as-is: you determine the "good" point is commit 1, and the ...um, other good point is commit 5? Well, that doesn't work. I guess we have to arbitrarily ignore commit 5 and say commit 4 is bad. A bisect will show that. Then in Fossil, if you visit the /info page for commit 4, it will show its child commit 5 as fixing the problem. Try again. Squashing doesn't solve anything here.

aidenn0 6y ago
I'm rebasing because the problem from commit #2 isn't fixed. We have a test that shows the problem from commit #2. However commit #4 breaks things in some way that the test we are running can't run. Squashing the commits together fixes this. If commits #4 and #5 were both on a feature branch before merging, squashing would be done by rebasing in the feature branch. I'm not saying all commits from a feature branch should be squashed to a single commit, but commits like "oops forgot to update header file" or some such are noise. Rewriting history is about improving the signal-to-noise ratio. You may lose some signal (the Fossil argument against it), but if you lose more noise than signal it may be worth it (the git argument for it).