3 ms·

I've seen `git push -f` used quite a bit over my career. Maybe it's bad practice, but it's useful for: 1. Organizations that want single-commit branches (e.g.,

I've seen `git push -f` used quite a bit over my career. Maybe it's bad practice, but it's useful for: 1. Organizations that want single-commit branches (e.g., where there's a lot of cherry picking going on in a git-flow style to get certain features pushed out) but you also want to keep 'savepoint' commits while developing. Squashing a bunch of commits requires a -f if you've already pushed. 2. Rebasing a branch (without making a bubble merge). 3. For truly small quick fixes you notice when you've just pushed to CI (like you left in a debug or a focus on some tests).

sjrd 11y ago
Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git bisect`ing things later. They are also necessary to keep a history where `git blame` can be used effectively.
- brianwawok 11y ago
  Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ? I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick. As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!
  - mmanfrin 11y ago
    On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.
    - brianwawok 11y ago
      Sure but I think OP was advocating rebasing a shared branch so that git bisect would always pass on each commit
      - setpatchaddress 11y ago
        git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.
        brianwawok 11y ago
        You usually won't lose commits with reflog, especially the more users of a repo the more reflogs.. but yes a disaster to go find them again...
  - peteretep 11y ago
    As long as you can communicate the change to other branch users, I don't see the problem?
mhartl 11y ago
Oh, for sure. I use it all the time. There's no doubt `git push -f` is useful. Even less doubt that it's dangerous. ;-)

sjrd 11y ago

Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git bisect`ing things later. They are also necessary to keep a history where `git blame` can be used effectively.

brianwawok 11y ago
Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ? I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick. As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!
- mmanfrin 11y ago
  On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.
  - brianwawok 11y ago
    Sure but I think OP was advocating rebasing a shared branch so that git bisect would always pass on each commit
    - setpatchaddress 11y ago
      git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.
      - brianwawok 11y ago
        You usually won't lose commits with reflog, especially the more users of a repo the more reflogs.. but yes a disaster to go find them again...
- peteretep 11y ago
  As long as you can communicate the change to other branch users, I don't see the problem?

mhartl 11y ago

Oh, for sure. I use it all the time. There's no doubt `git push -f` is useful. Even less doubt that it's dangerous. ;-)