4 ms·

Force push is never a mistake. You have to explicitly add the force flag, and if you choose to go down that path, then you better be sure you know what you're

by npinguy 13y ago

Force push is never a mistake. You have to explicitly add the force flag, and if you choose to go down that path, then you better be sure you know what you're doing. If you don't, but still manually setting that flag to fix the error that your push failed? You deserve the rain of hellfire that will come down upon you if you blow away other people's commits. I know about denyNonFastForwards, and unfortunately I work at a company that turns this on as a rule on ALL branches, which I don't like because I like having personal branches on the server (rather than on my personal git repo). As a result when I want to squash my commits I end up rebasing interactively, deleting the remote branch, and then creating it again.

StefanKarpinski 13y ago
I guess you've never written an automated tool that works with remote repositories and sometimes has to force them. It's quite possible to accidentally force push a branch that way – and that appears to be precisely what happened here. Sure, he maybe could have been more careful and avoided the mistake, but GitHub could incredibly easily allow people to configure repos so that this mistake can't be made. Your argument boils down to "don't make mistakes", whereas my point is that in this case it would be so easy for GitHub to give repo admins the ability to prevent this entire class of mistakes. [Note that using an explicit branch name, as has been suggested here, doesn't really help since you can easily accidentally force push a branch that way too.] The fact that your company has a draconian blanket policy is unfortunate, but has no bearing on whether or not people should be allowed to opt in to setting denyNonFastForwards on specific branches.
lukeschlather 13y ago
Where I work they have a very effective strategy for dealing with this problem: there's a magic 'backup' remote you can push to that is unique to each user and allows --force. Backing up your local feature branches is no reason to enable rewriting history on the main repository.

by npinguy 13y ago

StefanKarpinski 13y ago

I guess you've never written an automated tool that works with remote repositories and sometimes has to force them. It's quite possible to accidentally force push a branch that way – and that appears to be precisely what happened here. Sure, he maybe could have been more careful and avoided the mistake, but GitHub could incredibly easily allow people to configure repos so that this mistake can't be made. Your argument boils down to "don't make mistakes", whereas my point is that in this case it would be so easy for GitHub to give repo admins the ability to prevent this entire class of mistakes. [Note that using an explicit branch name, as has been suggested here, doesn't really help since you can easily accidentally force push a branch that way too.] The fact that your company has a draconian blanket policy is unfortunate, but has no bearing on whether or not people should be allowed to opt in to setting denyNonFastForwards on specific branches.

lukeschlather 13y ago

Where I work they have a very effective strategy for dealing with this problem: there's a magic 'backup' remote you can push to that is unique to each user and allows --force. Backing up your local feature branches is no reason to enable rewriting history on the main repository.