3 ms·

No, the issue is force pushing. While it's nice that git changed the default behavior to be far less dangerous, people with push access can still force push – b

No, the issue is force pushing. While it's nice that git changed the default behavior to be far less dangerous, people with push access can still force push – be it one branch at a time in newer gits or all branches in older ones. It's all fine and well to tell them to change their settings and/or ask them please don't force push, but people make mistakes. Hell, I want to prevent myself from accidentally doing this. Git let's you prevent this easily using the receive.denyNonFastForwards option, but GitHub won't let you control this option. So we're left just telling people not to do it and hoping that they listen and don't do it by accident. That seems like a shitty, precarious situation that could easily be fixed. One checkbox on the GitHub repo settings page and this story would never have happened. [1] http://stackoverflow.com/questions/13016119/how-to-set-the-receive-denynonfastforwards-on-a-repository-in-github http://stackoverflow.com/questions/13016119/how-to-set-the-r...

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.
bgrainger 13y ago
> GitHub won't let you control this option They do, in GitHub Enterprise. However, the option is not in the "public" Repo Settings page; it's in a special site-admin-only settings page. So it seems possible that this same setting could be deployed to github.com, but it would need additional UI development.

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.

bgrainger 13y ago

> GitHub won't let you control this option They do, in GitHub Enterprise. However, the option is not in the "public" Repo Settings page; it's in a special site-admin-only settings page. So it seems possible that this same setting could be deployed to github.com, but it would need additional UI development.