3 ms·
It's used often in a team where you each have your own forks. It's much less risky in such a case, of course. Basically, I push to my fork, then later I pull-wi
by encoderer 13y ago
It's used often in a team where you each have your own forks. It's much less risky in such a case, of course. Basically, I push to my fork, then later I pull-with-rebase from the mainline, then I push again to my fork. Oops, commit hashes have changed because of my pull-with-rebase. So I need to either push to a different branch or force push.
- bad_user 13y agoYour problem is that you shouldn't be doing pull with rebase so often. A clean merge doesn't have to rewrite anything.
- swift 13y agoI'm not sure a "problem" exists here. Keeping your personal topic branch rebased on top of the main development branch is a perfectly reasonable workflow, and quite comparable to what you'd do with Mercurial patch queues.
- mst 13y agoAnd in a team where everybody's used to that, and force is only ever used on topic branches where that's the expected 'done thing', it really doesn't cause a problem. (on teams that like rebase I tend to do this a lot)
- encoderer 13y agoExactly. Though it is a bit of a moral hazard... or maybe that's not the right term... point is, users get used to "-f" ing pushes.
- encoderer 13y agoAgree with Swift. Having a rebase strategy keeps history linear and MUCH easier to read.