Hacker News Reader

Comment by spullara | Hacker News Reader

Wouldn't it be great if your scm actually kept all your changes no matter what?

As far as I understand, git actually always keeps your changes. It is just the pointers that can be overridden if you force an update. For instance,

  git reflog show origin/master

shows even remote forced-updates. So although it looked like the commit was lost, it was still there, just not immediately visible, and was fully recoverable.

Yeah, exactly. We (GitHub) use reflogs on the server, so everything that was pushed was in the repository and can't be gc'd out for at least 90 days. The master branch ref was just pointing at the wrong commit due to the forced pushes.

Reflogs are a lifesaving Git feature, but I imagine a large proportion of "casual" Git users don't know they exist, not least because a lot of people's Git education comes from poking around the GitHub interface.

It'd be amazing if GitHub began exposing reflogs through the web somehow.

You can lose commits if you use git gc but you're probably aware of what you're doing when you do that.

Even with git gc you have to try pretty hard to lose updates -- I believe by default it will leave stuff only reachable from the reflog around for 90 days.

(I <3 git.)

I mean, "-f" is for forcing overwriting of changes.

The other developer had several recourses.

The awesome ProGIT book: http://progit.org/

The hotness of the GitReady: http://gitready.com/

The great MAN pages of course: http://www.kernel.org/pub/software/scm/git/docs/

GitCasting like a boss: http://gitcasts.com/

GIT users on IRC: irc://freenode.net/git

And of course, Github itself. They're awesome in a box: http://help.github.com/

Regardless, it's nice to see a developer publicly admit the error of his ways, and even nicer to see other developers brush it off and keep going as they give support.

Bald-faced pimping of a resource the company I work for, EdgeCase, put together as well: http://gitimmersion.com/

That's like saying: wouldn't it be great if your filesystem kept all your files no matter what. Well, no, there are instances where you want to actually throw things out. The push man page specifically says:

  -f, --force
    Usually, the command refuses to update a remote ref that is not an
    ancestor of the local ref used to overwrite it. This flag disables
    the check. This can cause the remote repository to lose commits;
    use it with care.

And even with that, the commit wasn't lost yet. It likely in the reflog of the remote repo, and in the history of whichever repo the change was originally pushed from.

That said, there are ways to lose work with git that aren't recoverable ("reset --hard" silently overwrites uncommitted work), but this isn't one of them.

The difference being that an SCM records the history of your project. It would certainly be possible to record this simply as a "forced overwrite" in the history.

Which git sort-of does (reflog). And then, after it prevented you from shooting yourself into the foot, it gives you a loaded Howitzer pointed at your face. (git reflog expire/git prune/git gc)

I love git dearly, but that's still a large flaw in its design. There is no reason to ever lose history.

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.

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