Hacker News Reader

Comment by stefan_kendall3 | Hacker News Reader

"git push -f" will no longer ruin days (as badly)

Possibly 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.

... due to force pushing multiple branches?

I'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.

It 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.

The 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.

Ah, I see. Thanks for clarifying.

`push -f` and `workflow` should never be in the same sentence.

Exactly. 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.

I 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.

I have never had the need to force a push. What are the circumstances that would require it?

you 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).

That 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.

> 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.

Reply on news.ycombinator.com