7 ms·

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 the

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.

dilap 13y ago
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.
- Anderkent 13y ago
  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?
  - dilap 13y ago
    Oh, interesting, I think you're right. That's a bit unfortunate actually!
  - darklajid 13y ago
    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?
    - luchs 13y ago
      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.
  - eridius 13y ago
    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.
- judk 13y ago
  Today I suddenly realized reflog is "ref log" not "re flog". My world just got a bit less magical.
  - eru 13y ago
    Has someone told you about "we blog" yet?
    - seguer 13y ago
      Isn't it "web log"?
      - eru 13y ago
        At the expense of dissecting the frog: yes, that was the joke. (And whoever downvoted you is a jerk.)
dpatrick86 13y ago
Wow, that is pretty dramatic. I'm almost surprised I haven't accidentally done that one.
golergka 13y ago
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.
- 10char 13y ago
  If you had the `-f` (force) flag, it overrides any sanity checks and simply accepts whatever history you give it.
  - davvid 13y ago
    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.
matwood 13y ago
Bitbucket lets an administrator mark branches as not rebasable (or deletable). Very useful feature to avoid exactly what you describe.
- ollysb 13y ago
  That's a really nice feature, I'd like to see github offer that.
  - kevining 13y ago
    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.
hkarthik 13y ago
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.
ramblerman 13y ago
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.
- MaxGabriel 13y ago
  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.
  - deleted 13y ago
    [deleted]
  - ori_b 13y ago
    > 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.
    - Hovertruck 13y ago
      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.
    - pseut 13y ago

dilap 13y ago

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.

Anderkent 13y ago
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?
- dilap 13y ago
  Oh, interesting, I think you're right. That's a bit unfortunate actually!
- darklajid 13y ago
  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?
  - luchs 13y ago
    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.
- eridius 13y ago
  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.
judk 13y ago
Today I suddenly realized reflog is "ref log" not "re flog". My world just got a bit less magical.
- eru 13y ago
  Has someone told you about "we blog" yet?
  - seguer 13y ago
    Isn't it "web log"?
    - eru 13y ago
      At the expense of dissecting the frog: yes, that was the joke. (And whoever downvoted you is a jerk.)

dpatrick86 13y ago

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

golergka 13y ago

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.

10char 13y ago
If you had the `-f` (force) flag, it overrides any sanity checks and simply accepts whatever history you give it.
- davvid 13y ago
  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.

matwood 13y ago

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

ollysb 13y ago
That's a really nice feature, I'd like to see github offer that.
- kevining 13y ago
  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.

hkarthik 13y ago

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.

ramblerman 13y ago

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.

MaxGabriel 13y ago
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.
- deleted 13y ago
  [deleted]
- ori_b 13y ago
  > 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.
  - Hovertruck 13y ago
    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.
  - pseut 13y ago