Alternatively use git the way it was meant to be used, as a distributed source control system. It appears that they had 678 people sharing access to these repos instead of working off their own forks. I'm amazed they haven't stepped on each others toes previously with that structure.
> Alternatively use git the way it was meant to be used, as a distributed source control system.
Let's not be disingenuous. This is exactly what every git user does when they run `git clone`. You aren't railing against just multiple committers per public repo, you're railing against multiple clones per public repo. One user swapping between two client systems can make this error. Most public repos of any scale will have multiple committers to spread the maintenance workload.
Even Scott Chacon himself describes a simple, effective process called "GitHub Flow"[1] -- just submitting a PR against a branch for merge against master on the same repo. This is a very common workflow on private repos in my experience, and a very easy workflow for small teams.
Making all this worse, the default config setting for `push.default` will only change to "simple" in Git 2.0 -- until then any new host/account that hasn't had push.default changed in .gitconfig is a bomb waiting for the first otherwise legitimate `git push --force` to go off. I've received the batsignal from folks on small teams who've otherwise done all the right things and still been bitten by this.
Fortunately, git has the reflog[2][3] to save us from this kind of mess. It's just not readily accessible on GitHub, AFAICT.
Update: there's a critical caveat to remote reflogs:
core.logAllRefUpdates must be manually enabled on bare repos!
To repeat: the reflog is not available on bare remotes by default unless core.logAllRefUpdates has been manually set to "true". See [1] for documentation on that config setting.
Agree 99%, but it's more "use Github" than "use git" as it's meant to be used. GH supports certain development modes very well, fork+push request being the best, but having zero support for ACLs on branches or files makes other dangerous. As the devs in question are finding out (and as I have found out previously on a much much smaller scale, so no schadenfreude here.).
(You could argue that stock git doesn't really support fancy permissions models either, but if you have access all the hooks you can implement them, or you can use gitolite or Gitlab.)
I agree that git doesn't strictly enforce a team workflow, but 'pull requests' predated github and many use a pull request based workflow without github. Having a local fork, a remotely accessible fork, and asking the repo maintainer(s) to pull from your remote repo to merge into the release repo doesn't require github and many projects use that structure without using github at all, most prominently, the linux kernel. `git request-pull` is a built in command after all.
Considering that forks are basically heavyweight branches, I don't get your point.... it's distributed just as much whether they merge from another branch or another repository.
I think forks aren't anything like branches in Git. Forks are clones. By your logic, every clone is just a "heavy duty branch" which doesn't compute for me. Ya know?
> By your logic, every clone is just a "heavy duty branch" which doesn't compute for me. Ya know?
That's exactly what I mean. How is this a difficult concept? Branches are lightweight, clones are heavyweight. There's really very little difference except that they can share branches of the same name that point to different refs, I guess.
git can support centralised systems just as well as subversion or any other vcs. You'll note from the thread had they been using a real git repository a quick look at the reflog would have fixed this. Not to mention disabling forced pushes is available in their enterprise version of github as well as standard git.
Ah true it appears from some SO responses you can contact support and they can restore it. But there appears no way to access the server's reflog through github or is there?
