4 ms·

> I reject the argument that a no-rebase, merge-only history "preserves the true history of how commits were created", because I believe that is irrelevant. Wha

• singpolyma3 2y ago
  Code doesn't exist until it is merged, so these are equivalent
  • Nullabillity 2y ago
    Err, what? If I'm trying to fix the PR, the distinction is often a critical starting point for finding the root problem.
    • lolinder 2y ago
      If your PR is big enough that you're relying on a git bisect to find a bug, that's a problem in its own right. A workflow like what OP is describing (code doesn't exist until it's merged) typically also assumes that your PR is one atomic change, not a whole feature. You'd use feature flags or something similar to decide when to actually release a feature, not the PR process.
      • Nullabillity 2y ago
        > If your PR is big enough that you're relying on a git bisect to find a bug, that's a problem in its own right. Who said anything about bisecting? But yes, sometimes changes are big and I'd rather land them as one cohesive unit that demonstrates how it actually solves the root issue than get stuck down a wrong path because "this is what we already landed the infra for". > A workflow like what OP is describing (code doesn't exist until it's merged) That's not a workflow, it's a misunderstanding of reality.