31–40 of 49 posts
I'm a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.
But a simpler answer may be that it was just hard to implement.
I'm a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.
As a mercurial user, how easy IS it to accidentally force-push in Git? You have to really go out of your way to do it in mercurial, and I haven't found any reasons to do so.
> how easy IS it to accidentally force-push in Git? It's easy to accidentally force-push to the wrong branch . If you're on the wrong branch (e.g. you think you're on your personal dev branch and want to update it after a rebase but you're actually on the mainline) `git push -f` will ruthlessly clobber the remote.
I'm a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.
Github still offer pretty weak configuration of permissions. e.g. the Dolphin team decided against migrating to Github due to the poor flexibility in permissions. https://dolphin-emu.org/blog/2015/09/01/dolphin-progress-rep... You can't have users who have the ability to triage issues without also giving them write access to the repository. https://help.github.com/articles/permission-levels-for-an-or...
Gitlab has similar thing to prevent checkins. Glad similar feature is coming to github as well..managers in enterprises will be happy..
Earlier quoted context omitted.
> Does the "required status check" thing apply to `git push`, or just to the merge button on the website? It applies to all ways of updating git: push, the web UI, merging, and the API. > how do you trigger a status check to run on your actual merge/rebase as made in your local client, which will almost certainly differ in SHA1 and may differ in content from the merge made in the PR? If they differ in SHA1 but not co…
Thanks! That's a very sensible model. I suppose it means that the status-check API can't be used to check that the history of a branch is up to some standards, like commit messages following a style or all commits in history passing some check, but that's fine. (It is a bit at odds with the documentation of the status-check API, which implies that it's about refs, not trees.)
Thanks for you comments about per-commit linting. We'll give them some thought.
This sounds like the wrong solution to me. The problem isn't (or rather, is rarely[1]) that you've "polluted" a public branch with bad code. Bad code gets pushed into branches by perfectly legal commits all the time, and you fix it via software engineering and not administrative policy. The real problem with the accidental force push is that it's lossy. The OLD head, to which you would hope to revert when you realize…
> Track the head of each branch at each point in "monotonic server time oof talk about over-engineering. What is the point? Just don't allow force pushes to protected branches is a much simpler model than. "Keep a bunch of bookkeeping meta data in the event of an unanticipated force push". All this complexity would only save you during the span of time those objects were collectible but not yet collected.
Earlier quoted context omitted.
> Track the head of each branch at each point in "monotonic server time oof talk about over-engineering. What is the point? Just don't allow force pushes to protected branches is a much simpler model than. "Keep a bunch of bookkeeping meta data in the event of an unanticipated force push". All this complexity would only save you during the span of time those objects were collectible but not yet collected.
Not really following your point. What I described could be implemented by a post-update hook that just ran "git rev-parse HEAD" and stuffed the result into a database somewhere. If anything it's significantly easier to implement than an authorization model.
Earlier quoted context omitted.
Not really following your point. What I described could be implemented by a post-update hook that just ran "git rev-parse HEAD" and stuffed the result into a database somewhere. If anything it's significantly easier to implement than an authorization model.
I'm not following where you are going. If these database records point to objects in the git database. How will you synchronize garbage collection and the state of the database?
I'm a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.
I don't think github was created with a shared repository model in mind. If you are forking which is the implied model this feature is relatively pointless because they offer you "pull only" from forks.