4 ms·

I don't see how rebasing often and keeping a linear history is in any way a worse workflow than letting merge bubbles happen. To the contrary, I've changed my p

I don't see how rebasing often and keeping a linear history is in any way a worse workflow than letting merge bubbles happen. To the contrary, I've changed my preferences from the latter to the former because it turned out to be more readable and to make it easier to find commits that introduced bugs or contain badly done merges.

derriz 7y ago
If there's more than one person working on the code base, rebasing is only safe if you restrict pushing/pulling in some way. Properly interleaving pushes and rebases is just more mental load and another way to shoot yourself in the foot with git. And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. But like I said, I've given up arguing about it and have reluctantly embraced my inner rebaser. A small part of me still feels it's a regression.
- einpoklum 7y ago
  If your rebasing only rewrites history up to a point that's shared by everyone working on the same branch as you, I don't see what's the big problem. > And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. You haven't, others (like me) have...
- dahart 7y ago
  If your team is rebasing already public history, then you’re right. Is that what you’re talking about? History should be cleaned up locally before pushing elsewhere. Once pushed, history shouldn’t be rewritten except in emergencies, and even then it should be discussed and communicated and everyone should agree a rewrite is better than more pushes to fix the problem. A case where a rewrite is preferable is when someone accidentally checks security keys into git, for example. Rebasing before pushing should be embraced, are you sure that’s not the majority of what’s happening?
  - jayd16 7y ago
    The issue is its easy to screw up this advice. This is like saying only look down the barrel of a gun if you know its not loaded.
    - dahart 7y ago
      How so? And which part? I think it’s difficult to rebase already pushed history accidentally, because that requires a force push. You have to opt-in and take action to do it, so it’s not easy to screw up unintentionally.
      - jayd16 7y ago
        Well you can say having to force is a solid barrier but you'll see plenty of comments suggesting that as well as plenty of comments stemming from having had to clean it up.
        dahart 7y ago
        Sure, but that’s completely different from your hyperbolic analogy of looking down the barrel of an unloaded gun. Force push has a solid barrier, it is not default behavior, it gives you warnings, the manual gives warnings, and if you read anything online you’ll find many warnings against. If people still do it not knowing what they’re doing, yes it can definitely cause problems, but you can’t call it an accident or easy to screw up.

derriz 7y ago

If there's more than one person working on the code base, rebasing is only safe if you restrict pushing/pulling in some way. Properly interleaving pushes and rebases is just more mental load and another way to shoot yourself in the foot with git. And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. But like I said, I've given up arguing about it and have reluctantly embraced my inner rebaser. A small part of me still feels it's a regression.

einpoklum 7y ago
If your rebasing only rewrites history up to a point that's shared by everyone working on the same branch as you, I don't see what's the big problem. > And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. You haven't, others (like me) have...
dahart 7y ago
If your team is rebasing already public history, then you’re right. Is that what you’re talking about? History should be cleaned up locally before pushing elsewhere. Once pushed, history shouldn’t be rewritten except in emergencies, and even then it should be discussed and communicated and everyone should agree a rewrite is better than more pushes to fix the problem. A case where a rewrite is preferable is when someone accidentally checks security keys into git, for example. Rebasing before pushing should be embraced, are you sure that’s not the majority of what’s happening?
- jayd16 7y ago
  The issue is its easy to screw up this advice. This is like saying only look down the barrel of a gun if you know its not loaded.
  - dahart 7y ago
    How so? And which part? I think it’s difficult to rebase already pushed history accidentally, because that requires a force push. You have to opt-in and take action to do it, so it’s not easy to screw up unintentionally.
    - jayd16 7y ago
      Well you can say having to force is a solid barrier but you'll see plenty of comments suggesting that as well as plenty of comments stemming from having had to clean it up.
      - dahart 7y ago
        Sure, but that’s completely different from your hyperbolic analogy of looking down the barrel of an unloaded gun. Force push has a solid barrier, it is not default behavior, it gives you warnings, the manual gives warnings, and if you read anything online you’ll find many warnings against. If people still do it not knowing what they’re doing, yes it can definitely cause problems, but you can’t call it an accident or easy to screw up.