> 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.
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.
[1] http://scottchacon.com/2011/08/31/github-flow.html [2] http://gitready.com/intermediate/2009/02/09/reflog-your-safe... [3] https://www.kernel.org/pub/software/scm/git/docs/git-reflog....