Hacker News Reader

Comment by Gigablah | Hacker News Reader

We were burnt by this before -- someone did a "git push -f" thinking it would force push only their current branch. It ended up pushing everything including their master which was out of date, thus wiping out a whole bunch of newer commits. Luckily it was also easy to restore due to git's distributed nature.

View on HN

Why would you use -f unless you are doing something really peculiar.

If you are behind git warns you and says you need to pull first. By stating -f you are saying nope, throw that crap away and just take my version.

That's pretty extreme and warrants care. I have a hard time feeling sorry for people who are burned by this.

It's not unreasonable to force push a branch. Anytime you've rebased but already pushed you would need to do so. I've worked on an open source project where every commit was required to pass all the tests, so if you submitted a PR that had any commit fail CI, you would have to alter history and force push.

I also just like pushing to a branch on Github, even if I might rebase later. Circle CI is triggered through Github, so it's nice to have that triggered for me. Our staging servers (production data, your branch's code) are deployed from Github branches as well. Plus looking at diffs on Github is really helpful for me to spot errors—I'm not sure if it's the context switch away from my text editor, Github's diff UI, or what, but it works for me.

> Anytime you've rebased but already pushed you would need to do so.

And that's also unreasonable. Pushed history should be treated as immutable. If you broke the build, push a revert commit, fix the issue, and resubmit. And then fix your tooling to recognize rollbacks.

I tend to treat the history of the master branch as immutable. Working with a remote branch that needs to stay up-to-date with master has, in my experience, required rebasing and force-pushing the branch.

In this case, the person probably thought he or she was pushing "feature-wip" or something similar after cleaning up that branch's history. Not necessarily unreasonable. If master is out of date then

    git push -f

throws away any remote commits (under old behavior).

I actually made this exact mistake yesterday:

* I made a topic branch and push it for review on github

* I immediately found a trivial typo in my code

* I amended my commit to fix the typo

* I did push -f to overwrite the topic branch on

* OOPS. I pushed all my branches. >.<

It doesn't seem peculiar at all, to me.

Even w/o the distributed stuff, git reflog has your back. Once something has been comitted, you have to try pretty hard to really lose it.

That's only if you have ssh access to the server. I don't think there's a way of seeing the reflog of a remote? I.e. if you're using github and the branch only lives there, can you undo an overwrite?

Oh, interesting, I think you're right. That's a bit unfortunate actually!

I guess I am missing something. There is no 'server'. You should have the same reflog locally, if you pulled before someone messed the repository up?

The 'server' in this case is a remote repository which has some commits you don't have. If you force push to this repository, these commits will be lost for you - only the person who pushed these or someone with access to the server can restore them.

If you have the output from your `git push -f` you can, because it outputs both the old and new ref for each modified branch.

Today I suddenly realized reflog is "ref log" not "re flog". My world just got a bit less magical.

Has someone told you about "we blog" yet?

Isn't it "web log"?

At the expense of dissecting the frog: yes, that was the joke. (And whoever downvoted you is a jerk.)

Bitbucket lets an administrator mark branches as not rebasable (or deletable). Very useful feature to avoid exactly what you describe.

That's a really nice feature, I'd like to see github offer that.

They do! But unfortunately there's no UI for this =(

You can contact their support and they will enable this for you. They have great support and usually get back to me within a few hours.

I think every large team using Git has experienced the Git Force Push Master clusterfuck at least once. It's usually right after this that a mandatory gitconfig gets passed around.

Wow, that is pretty dramatic. I'm almost surprised I haven't accidentally done that one.

Strange. I'm not a git expert, but every time I try to push outdated commits to the origin, it says that I'm behind and need to pull first.

If you had the `-f` (force) flag, it overrides any sanity checks and simply accepts whatever history you give it.

If `git config receive.denyNonFastforwards true` is configured on the remote repository then this is prevented. This is the default on modern versions of Git.

Reply on news.ycombinator.com