4 ms·
"git push -f" will no longer ruin days (as badly)
by stefan_kendall3 13y ago
"git push -f" will no longer ruin days (as badly)
- penguindev 13y ago... due to force pushing multiple branches?
- glasser 13y agoExactly. Doing that by mistake (and then being taught to set `push.default` to upstream or simple) has been a rite of passage for engineers at my company.
- markmark 13y agoI never quite understood why the default was what it was. I can count the times I've wanted to push all branches at once on no hands. But maybe that's just my work flow.
- stefan_kendall3 13y agoI've seen someone do it. If your workflow is 'git push -f feature' after rebasing, instead of 'git push feature -f', you can tap enter and break the world.
- penguindev 13y agoIt really blows my mind that you say those two aren't equivalent. I now must read the man pages... Edit did you mean to say (plus)feature or is something ruining the formatting? That seems to be how to specify only one branch. Yuck. I'm lucky I haven't run into this, I guess, because I set my push default to simple a long time ago, so long ago I can't even remember why.
- stefan_kendall3 13y agoThe two are equivalent if you type them in full, but if you stop one before typing the feature branch name, you've broken everything. git push -f (enter) => Death to all branches. git push feature -f => Can only ever force push the feature branch No matter when you press enter in the second line, intentionally or accidentally, you can't break all branches.
- penguindev 13y agoAh, I see. Thanks for clarifying.
- mikeklaas 13y ago`push -f` and `workflow` should never be in the same sentence.
- acchow 13y agoPossibly the most confusing default in git. My gitconfig has: [push] config = default default = tracking I once made a virtual machine and didn't pull in my usual .gitconfig. It ruined my day.
- beagle3 13y agoI have never had the need to force a push. What are the circumstances that would require it?
- penguindev 13y agoyou have a private feature branch on git hub, clean it up via rebase (or just rebase to latest master) before review, and you need to force push it. on long running features, you 1. want to save your state off of your laptop and 2. keep it clean for your own review and for others' review. thus, force push is required, otherwise you'd have to keep making new revs of your branch (branch named joeblow/my_feature_rev_4).
- beagle3 13y agoThat looks so wrong to me. It says everywhere in the docs "never rebase something that's been published" and it says so for a reason. The fact that git lets you shoot yourself in the foot doesn't mean you should, definitely not incorporate this into working procedures. If it's a private feature branch, don't make it public (pushing would still back it up on the server, though you'd have to know the sha1 to fixed it). If it's public, don't rebase it.
- penguindev 13y ago> and it says so for a reason. And yet you don't know the reason. It's because others may have merged your work or be dependent on it. In my case, that doesn't happen, because it's a private branch. I'm the only developer, but other people can look at it for review.