4 ms·

The `git push --force` command didn't quite make the cut, but if you can think of a place where it fits into the current tutorial I'm certainly open to adding i

by mhartl 11y ago

The `git push --force` command didn't quite make the cut, but if you can think of a place where it fits into the current tutorial I'm certainly open to adding it. Maybe it fits in as an exercise somewhere? UPDATE: yebyen has suggested this was a meant as a joke. If so—good one! UPDATE 2: I don't mean to imply that force-pushing isn't useful! As several commenters below have noted, it most certainly is. But it's also most certainly dangerous.

yebyen 11y ago
I think that was supposed to be a joke. Enough git to be dangerous... what about some dangerous git command which potentially destroys some important history... [stopgirl.gif] Your books are great, I've been buying Learn Enough to be Dangerous preorders for topics I already know well because I learned so much from the Rails Tutorial dot-org. Thanks!
- mhartl 11y ago
  Heh, I almost replied that `git push --force` might be a little too dangerous! But the truth is it barely didn't make the cut, and I wouldn't mind finding a place to work it in.
mmanfrin 11y ago
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.
- 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. ;-)
yawaramin 11y ago
git push --force-with-lease https://webcache.googleusercontent.com/search?q=cache:TKD0MW3spoYJ:https://developer.atlassian.com/blog/2015/04/force-with-lease/+&cd=1&hl=en&ct=clnk&gl=ca https://webcache.googleusercontent.com/search?q=cache:TKD0MW...

by mhartl 11y ago

yebyen 11y ago

I think that was supposed to be a joke. Enough git to be dangerous... what about some dangerous git command which potentially destroys some important history... [stopgirl.gif] Your books are great, I've been buying Learn Enough to be Dangerous preorders for topics I already know well because I learned so much from the Rails Tutorial dot-org. Thanks!

mhartl 11y ago
Heh, I almost replied that `git push --force` might be a little too dangerous! But the truth is it barely didn't make the cut, and I wouldn't mind finding a place to work it in.

mmanfrin 11y ago

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

yawaramin 11y ago

git push --force-with-lease https://webcache.googleusercontent.com/search?q=cache:TKD0MW3spoYJ:https://developer.atlassian.com/blog/2015/04/force-with-lease/+&cd=1&hl=en&ct=clnk&gl=ca https://webcache.googleusercontent.com/search?q=cache:TKD0MW...