Hacker News Reader

Comment by spullara | Hacker News Reader

So it appears that every response to my message said that it wasn't lost but would be in 90 days if no one noticed. That is not the definition of 'never loses changes'. The fact of the matter is that someone that doesn't understand the way git works can cause irreversible damage without recourse if not discovered. In many source control systems this is not the case. I still use git on github even with this flaw.

View on HN

The underlying problem is that GIT was never meant as a centralized scm. A centralized source control system will never lose changes, even if one of the users messes up. This means that it distinguishes between normal committers and 'admins'. Only admins can do irreversible actions.

Git uses local, cloned repositories and users can do everything they like with them. Changes can be pushed and pulled to other repositories, possibly changing them irreversibly.

By using github you use GIT in a (kind of) centralized way. Suddenly there is an 'central project repository' again, that needs to be protected against damage. But as GIT was never meant to do this, and trusts its users, it has to be bolted on somehow... at least, that's how I understand it.

I hope they will get this right as it's very important for accountability.

You don't need to allow others write access to your repositories on github. Simply have them fork your public repository but don't add them as a collaborator. They can commit all they want and send you or any one of your 'admin' collaborators a pull request. This idea that git/github is losing changes is not true. You have at least until the next time the gc is run (90 days at github?), which is well beyond the time required to resolve the issue in any active project.

I think, though, that for "never loses changes" to be meaningful it has to be shorthand for "never loses changes unless you do unsafe things". I mean, it certainly loses changes if you don't push to anywhere and then delete your .git directory.

The -f should mean "don't do this, it will probably wreck your shit". Unfortunately certain tools seem to require it way too often so it seems to be going the way of the venerable confirm dialog.

"Deleted all my files? I dunno, some funny box popped up and I hit OK. Was that it?"

This user training gets even worse because git, when refusing to perform an unsafe operation, trains the user to force instead of training the user to fix the problem.

For example, the developer who overwrote the commits in the case in question probably did so after seeing the following error message:

  abort: push creates new remote heads on branch 'default'!
  (did you forget to merge? use push -f to force)

While it mentions merging, the only recognizable command line ("push -f") is for a destructive operation, instead of the operation (pull or merge, depending on the situation) that will actually fix the unsafe condition. Putting an even partial command line in front of a developer is like putting an OK button in front of a non-technical user - they tend to just use it to see if it (superficially) works. When it (subtly) fails, a novice user will not notice, and will just remember "push -f" as the Right Way to Use Git.

That appears to be an hg error message.

The git version is:

    $ git push github master
    To git@gitproxy:rip747/    cfwheels.git
    ! [rejected] master -> master (non-fast forward)
    error: failed to push some refs to ‘git@gitproxy:rip747/cfwheels.git’

That makes no mention of -f (or any git commands at all).

You can configure git-receive-pack to not allow ref deletes (receive.denyDeletes) or any ref updates which aren't fast-forwards (receive.denyNonFastForwards), which makes this kind of data loss impossible. With Gitolite you can even set this permission per-user per-branch (https://github.com/sitaramc/gitolite#_main_features) so that the great power is only given to those with the great responsibility to handle it.

Of course, somebody still has to know and care enough to want to tweak the default configuration, and it doesn't help with GitHub for the moment, but I wouldn't be surprised if they added finer-grained branch permissions in future.

Reply on news.ycombinator.com