5 ms·

There's an elephant in the room that he missed. Rebase breaks bisect. If you have a sequence of patches, wherein each patch compiles cleanly, and you merge it

There's an elephant in the room that he missed. Rebase breaks bisect. If you have a sequence of patches, wherein each patch compiles cleanly, and you merge it with another sequence of patches, you still have a sequence of patches that compiles cleanly. If however you rebase your sequence of patches onto another sequence, and this introduces build errors (not uncommon), bisect no longer works on this segment of history, even after you fix the build issues with a final "cleanup" patch. Rebase destroys semantic history. Merge preserves it. EDIT: whomever downvoted me, care to explain what's wrong with my reasoning?

sofal 14y ago
I did not downvote you, nor do I think you deserve a downvote. I think your scenario highlights something to be careful about when rebasing, but I wouldn't say to avoid rebasing because of it. You could, for example, do an interactive rebase to fix or squash those commits.
- colanderman 14y ago
  Yes, commit squashing is one way to work around this issue.
philwelch 14y ago
"If however you rebase your sequence of patches onto another sequence, and this introduces build errors (not uncommon), bisect no longer works on this segment of history, even after you fix the build issues with a final "cleanup" patch." Well, not if the cleanup patch goes at the end of that sequence rather than the beginning. Guess what tool you can use to change that. I don't really see how introducing a breaking change in a merge commit rather than a rebase fixes anything. In any case, you should squash, build locally, and fix before merging to master anyway.
- colanderman 14y ago
  Well, not if the cleanup patch goes at the end of that sequence rather than the beginning. That's what I meant by a "final cleanup patch". However this is not an issue that any sequencing of such patches can fix: Without rebase, every patch has an implicit implication that if it builds cleanly when applied to its parent, it builds cleanly no matter what other patches are merged into the tree in the future. Once you start rebasing, you lose that guarantee unless you edit the patches themselves: there's no guarantee that just because sequences A-B-C, A-D and A-D-E each build, that A-B-C-D will build. Hence bisect (which may need to build A-B-C-D) breaks.
  - philwelch 14y ago
    The thing is, when you rebase, you don't have A-B-C-D at all. If you have A-B-C and A-D and you rebase A-D onto A-B-C, you actually have A-B-C and A-B-C-D', where D' is the same diff as D, but it's a different revision. And when you build, you may find that D' doesn't work when D did. Merging doesn't even help, because if you merge A-D to A-B-C, you end up with: A-B-C-M \_D_/ at which point M would be broken in the same cases where D' would be broken.
    - colanderman 14y ago
      The point is M contains the fixes required to make A-B-C plus A-D build. Then you have no histories in that tree that don't compile. Like you said, A-B-C-D' DOESN'T build, PRECISCELY because D' is the same diff as D. You need to make A-B-C-D'-M to get a working build, but the history A-B-C-D' is STILL BROKEN.
      - philwelch 14y ago
        So you run a build on D', make the necessary fixes, and amend it. Which is exactly what you would have had to do with M anyway, or else M wouldn't build either. I don't see any difference at all. Merge commits don't magically fix broken builds. All they do is ensure that you've resolved merge conflicts, but rebases do the same thing!
npsimons 14y ago
I downvoted you because rebase doesn't break bisect, full stop.
- colanderman 14y ago
  That's not an explanation. Please address my argument.
  - npsimons 14y ago
    Neither is claiming that rebase breaks bisect; I can tell you what does break bisect: commits that are noise. Commits that weren't properly cleaned up. Commits that revert changes made in the previous commit. Commits that are conceptually related but not squashed together, or worse, separated by unrelated commits, etc, etc. You know what these have in common? They can be fixed with rebase. Sure, rebase can be abused, but committing in general can also be abused. Rebase offers the opportunity to make history legible, instead of just some ASCII journaling of a codebase. And you're also wrong about rebasing onto the tip of a branch, as others pointed out: in my experience, it very rarely introduces build errors, and on the rare occasion it does, it's easy enough to fix them, commit, rebase to squash into a fixed commit, and push. As someone who rebases on a regular basis, and has done more than a few bisects to the same codebase, I can tell tell you rebase works just fine with bisect. EDIT: I'm not the only one who thinks this way: http://darwinweb.net/articles/the-case-for-git-rebase http://darwinweb.net/articles/the-case-for-git-rebase
    - colanderman 14y ago
      Neither is claiming that rebase breaks bisect But I gave an explanation up front and took the karma hit. You hid behind your keyboard for two posts before explaining why you disagreed.
yxhuvud 14y ago
In that case you wouldn't do a cleanup patch - you would fix the original commits you made that broke things before pushing the changes.

sofal 14y ago

I did not downvote you, nor do I think you deserve a downvote. I think your scenario highlights something to be careful about when rebasing, but I wouldn't say to avoid rebasing because of it. You could, for example, do an interactive rebase to fix or squash those commits.

colanderman 14y ago
Yes, commit squashing is one way to work around this issue.

philwelch 14y ago

"If however you rebase your sequence of patches onto another sequence, and this introduces build errors (not uncommon), bisect no longer works on this segment of history, even after you fix the build issues with a final "cleanup" patch." Well, not if the cleanup patch goes at the end of that sequence rather than the beginning. Guess what tool you can use to change that. I don't really see how introducing a breaking change in a merge commit rather than a rebase fixes anything. In any case, you should squash, build locally, and fix before merging to master anyway.

colanderman 14y ago
Well, not if the cleanup patch goes at the end of that sequence rather than the beginning. That's what I meant by a "final cleanup patch". However this is not an issue that any sequencing of such patches can fix: Without rebase, every patch has an implicit implication that if it builds cleanly when applied to its parent, it builds cleanly no matter what other patches are merged into the tree in the future. Once you start rebasing, you lose that guarantee unless you edit the patches themselves: there's no guarantee that just because sequences A-B-C, A-D and A-D-E each build, that A-B-C-D will build. Hence bisect (which may need to build A-B-C-D) breaks.
- philwelch 14y ago
  The thing is, when you rebase, you don't have A-B-C-D at all. If you have A-B-C and A-D and you rebase A-D onto A-B-C, you actually have A-B-C and A-B-C-D', where D' is the same diff as D, but it's a different revision. And when you build, you may find that D' doesn't work when D did. Merging doesn't even help, because if you merge A-D to A-B-C, you end up with: A-B-C-M \_D_/ at which point M would be broken in the same cases where D' would be broken.
  - colanderman 14y ago
    The point is M contains the fixes required to make A-B-C plus A-D build. Then you have no histories in that tree that don't compile. Like you said, A-B-C-D' DOESN'T build, PRECISCELY because D' is the same diff as D. You need to make A-B-C-D'-M to get a working build, but the history A-B-C-D' is STILL BROKEN.
    - philwelch 14y ago
      So you run a build on D', make the necessary fixes, and amend it. Which is exactly what you would have had to do with M anyway, or else M wouldn't build either. I don't see any difference at all. Merge commits don't magically fix broken builds. All they do is ensure that you've resolved merge conflicts, but rebases do the same thing!

npsimons 14y ago

I downvoted you because rebase doesn't break bisect, full stop.

colanderman 14y ago
That's not an explanation. Please address my argument.
- npsimons 14y ago
  Neither is claiming that rebase breaks bisect; I can tell you what does break bisect: commits that are noise. Commits that weren't properly cleaned up. Commits that revert changes made in the previous commit. Commits that are conceptually related but not squashed together, or worse, separated by unrelated commits, etc, etc. You know what these have in common? They can be fixed with rebase. Sure, rebase can be abused, but committing in general can also be abused. Rebase offers the opportunity to make history legible, instead of just some ASCII journaling of a codebase. And you're also wrong about rebasing onto the tip of a branch, as others pointed out: in my experience, it very rarely introduces build errors, and on the rare occasion it does, it's easy enough to fix them, commit, rebase to squash into a fixed commit, and push. As someone who rebases on a regular basis, and has done more than a few bisects to the same codebase, I can tell tell you rebase works just fine with bisect. EDIT: I'm not the only one who thinks this way: http://darwinweb.net/articles/the-case-for-git-rebase http://darwinweb.net/articles/the-case-for-git-rebase
  - colanderman 14y ago
    Neither is claiming that rebase breaks bisect But I gave an explanation up front and took the karma hit. You hid behind your keyboard for two posts before explaining why you disagreed.

yxhuvud 14y ago

In that case you wouldn't do a cleanup patch - you would fix the original commits you made that broke things before pushing the changes.