Very classy apology. While Andrew's quickly jumping to conclusions is certainly not something to emulate (as he obviously implies in his apology), his ability to assume complete responsibility for a mistake that damaged a reputation is something all members of Internet communities should take note of.
Similarly, GitHub acted in a classy way too. Tom helped Andrew throughout the thread without any snark or dismissals that are, sadly, quite easy to dish out. It certainly contrasts with the recent "go away" Tumblr story.
I just looked up the post you were referencing. That was pretty shocking. As I mentioned earlier, this post deserves some recognition.
I screw up plenty, so I'm no stranger to apologizing to my partner. However, I could certainly take a page from the original poster. My apologies lack a certain degree of class!
Instant overreaction and posting to HN has come up a lot lately.
The Skype story yesterday was another mistake where a technical support person wrote that a bug was "by design" when they meant to type "bug," so of course it gets raced into HN as 'news' rather than trying to get clarification.
Indeed, this seems to be a sure fire way of getting some attention here lately. Experience some sort of inconsistency in service/support, and quickly write up an "expose" like blog post.
I think the lesson here is that for all our high-minded self-esteem, Hacker News is just as susceptible to hive-mind behavior as the sites HN users like to pooh-pooh.
I wish github (and git in general) had a better way to view the history of your history, as it were. It's great that get let's you change histoy, but it can be quite problematic if someone messes up that history, especially if it's not caught right away. Yes, it's in the reflog, but so is _everything_, so finding the right thing can be quite daunting.
No kidding, if I were GH I would be furious that that story was sitting at the top of HN (which is about as influential in the circles GH cares about as it gets) for the better part of a day.
It is great to admit but this is also good lesson for developers... you should always blame yourselves first; I have heard lots of funny stories over the years.
1.) I think there is an issue with the compiler :)
2.) The Java Classloader is broken :)
3.) Git is broken :)
My response -> "I will think of a million things it could possibly be on my way to your desk of those; the compiler, the classloader and git won't even be in the list"
3.) It doesn't work in IE 6...
Well ok, I guess the browser is the one area where blaming something else might be appropriate.
If after looking through all the possibilities that could be a reason for it not being your fault, stand up get a coffee and look at it again.
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.
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.
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.
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.
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.
This is something that always bothered me about git. Anyone with access to the repository can delete or overwrite a branch. Would be nice, if github had a way restrict deletes of a branch, or a prevent a force push. Not sure if git architecture actually makes this possible.
Wasn't there fiasco involving one prominent magazine for PC machines, where the author claimed that Vista was using all of the memory, while that memory in fact was cached.
But when in doubt, what happens with your cache on XP, Vista or Windows7 just use Mark Russinovich's RamMap. For example it helped me realize that NTFS compressed files, although compressed on disk would end up using the same amount of cache (memory). For that reason, it's probably better to store files compressed, rather than relying on NTFS.
