3 ms·

Your building strawmen does not help your credibility much, nor your attempt to convince me of your view. "Revisions that never existed" do exist, and if you pu

Your building strawmen does not help your credibility much, nor your attempt to convince me of your view. "Revisions that never existed" do exist, and if you put a rebase of a branch on master without verifying the rebase, then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason. Frankly, i find your style of argument through implication, and through trying to disregard something because it doesn't fit your definition of truth to be much more condescending than anything i wrote before.

MaulingMonkey 12y ago
> "Revisions that never existed" do exist "Revision that were never built nor tested" is probably closer to the truth. Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Sure, they're similar, and you probably didn't mess up the merges. There's likely no subtle lingering bugs that QA's only going to catch weeks down the line. Probably. > then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason. Sure. But I've missed so many things in code reviews, had so many things in my own code missed in code reviews, and generally make mistakes and messes. I do agree that simpler branch topology tend to be easier to reason about. But branches do have their advantages... and I've also found that preserving the original branch topology has helped me untangle merge mistakes that were missed, committed, and then only discovered a year or more later.
- Mithaldu 12y ago
  > Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Yes.
  - MaulingMonkey 12y ago
    I hope that's all automated with short build+test iteration times! That'd easily eat a day for minor feature branches for me - I can't afford that kind of turnaround time.

MaulingMonkey 12y ago

> "Revisions that never existed" do exist "Revision that were never built nor tested" is probably closer to the truth. Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Sure, they're similar, and you probably didn't mess up the merges. There's likely no subtle lingering bugs that QA's only going to catch weeks down the line. Probably. > then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason. Sure. But I've missed so many things in code reviews, had so many things in my own code missed in code reviews, and generally make mistakes and messes. I do agree that simpler branch topology tend to be easier to reason about. But branches do have their advantages... and I've also found that preserving the original branch topology has helped me untangle merge mistakes that were missed, committed, and then only discovered a year or more later.

Mithaldu 12y ago
> Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Yes.
- MaulingMonkey 12y ago
  I hope that's all automated with short build+test iteration times! That'd easily eat a day for minor feature branches for me - I can't afford that kind of turnaround time.