[lennartregebro]

And that simile also has nothing to do with what happened.

First of all, this is not a matter of me doing something wrong because I didn't learn enough of gits internals or didn't understand the cryptic the error message. The problem is that the error message appeared in the first place. In a sane revision control system, that would never have happened. Or at least, if a push fails because of a conflict, a git pull should have solved that.

This is not a matter of damaging the engine by revving it, or damaging anything else by misusing it. Because the history is not the engine, nor is it a child in a child seat. If you are going to use car similes, and you started it, then git is the car, and the history in your repo is your travels. The error message hence says:

"I'm sorry, you can't press the has pedal hard right now, because your engine is really a dwarf on a bicycle, and he is busy going to the loo. If you press the gas pedal hard now, the car will move, but you will suddenly appear where you were yesterday!"

Is that a sensible error message to you? Now, this is a road where you can take backup of where you are. So I did that, and tried, and to my astonishment the error message was right. The engine in my car was a dwarf on a bike, and I did find myself back where I was yesterday.

And the only way to avoid these things happening is : 1: backups or 2: Learning how the car is built from scratch, so I never press the wrong button or pedal again.

And you know what? That makes the car a crappy car. Requiring intimate knowledge about how to build and repair a car is something you needed in the infancy of automotive power. Not now. And it was something you needed when using RCS and CVS etc. Subversion solved that. Suddenly you could use a revision control system without knowing everything about how it is implemented in detail. But with git, we are suddenly thrown back to the RCS days.

That's the point, and that's why git sucks, and no misguided and incorrect car simile from your point can change that.

[saurik]

The goal of an analogy is to make you understand something that you did not understand previously by describing it in a different set of terminology. In this case, my analogy is only incorrect to you, as far as I can tell here, because you disagree with it so strongly you don't want to consider how it works.

I am thereby sorry that my analogy isn't quite working for you (indicating I could have tried harder), but if you could see the number of up votes it got given not-high this story got as a whole, you might consider spending some more time studying it to try to learn from it. I am going to try, though, as this may be valuable to others. Your complaint is that git failed to achieve its stated purpose: to never lose history, so lets examine what that means for the analogy.

In the case of the engine being destroyed, the car also failed to achieve its stated goal: to continue to be a vehicle for transport to new locations. The path the car travelled is thereby not a useful analogy, because it isn't something the car claims to do: it is a side effect of the car existing, and if you lost the path the car had previously travelled somehow you'd blame the space-time continuum, not the car.

The reason why git failed to do this, is because it trusts the user to know better than it in many of the same ways that a performance vehicle does. This is because both git and the car have similar secondary goals: they are willing to violate their primary mission statement to give the user easier access to direct control. Sometimes, direct control is dangerous.

To draw this again laboriously: the people who built the car understand that if it stops being a vehicle capable of moving you from one location to another, that sucks, and they technically could add features that make it very very difficult for you to break that; but, in the case of the performance-oriented vehicle, they chose not to do so, as maybe you actually are "making the call" to destroy the engine to, say, stop faster (I know someone who has done this, incidentally, someone who has a hobby maintaining and racing cars).

To compare, the people who developed git understand that if it stops storing your history in a way where you can always access it, that sucks, and while they technically could have made it more difficult for you to do that (either removing such features entirely or hiding them behind totally unrelated commands, like svnadmin), as they are making a lower-level engineer-focussed tool, they allow you to screw up and expect you to know what you are doing.

The analogy continues to be useful, as no one forced you to use the more advanced, lower-level, "raw", performance-oriented tool: you are welcome to use something that makes it very difficult to screw up. If you don't like Subversion (which has a lot of advantages for this use case) you can use Mercurial, which as far as I remember makes this kind of history manipulation quite difficult.

The situation here is simply that you chose a tool that you should not have and which did not match your expectations, and it isn't because the tool "sucks"... it is just because you aren't in the target market for the tool. The reason why people like myself are using git right now is not because it is somehow fundamentally better than Subversion at simple tasks (most of the complaints about Subversion are about old versions, honestly, and darcs seems to have a much better way of thinking about the concept of patches), it is because sometimes we run into really hard tasks that it makes possible (such as managing a distributed collective of thousands of engineers, some of which are totally disconnected from others).

It is then git's insistence to make some of these hard tasks possible that directly leads to the kind of "I lost my history?" problems you ran into. As as example, I just spent the last two days "manipulating the past" in order to take some code that I had previously been maintaining as part of two separate projects (with three separate copies...), and get it all pulled into a single place with a unified timeline that will allow me (or now others) to more easily maintain and understand it going forward, and that was easy: git is an amazing tool for this very kind of manipulation that arguably is defeating its purpose, but in fact is enabling it to be useful at all (as the distributed engineer case involves a lot of personal rebasing and push forcing).

Again, though, if you want something simple: use Subversion. I'm going to continue to use git. This is despite having been an early adopter of Subversion, despite having contributed patches to Subversion, despite having contributed code to third-party tools built for Subversion, despite having spent time bonding with the developers of Subversion around late-night literal-campfires, and despite disagreeing with much of the anti-Subversion hype.

This tool doesn't suck: you just don't understand the advantages of using a manual transmission currently, nor maybe does a manual (and unguarded) transmission actually offer you any advantages for your unique position in life. I get that, that's fine... but it had a warning label... it had a massive danger notice, as they know sometimes people but the wrong thing, and you seem to have ignored it... your insistence that all cars should be unbreakable workhorses actually trumped your willingness to believe that the people who built the tool were telling you the truth, and you ignored the warning. That isn't as fine ;P.

(topic change)

By the way, you may continue to have the complaint that one engineer using git can damage history for others using "push -f". In fact, I used to have this same complaint, and went on similar rants to this article regarding it, but instead of complaining about me and how I might purposefully or accidentally lose my own work, it was about how I couldn't trust the server to not allow others to accidentally lose my work. You might not be, but just in case, there are two answers to that.

First, that is actually a misuse of a distributed revision control system: GitHub mistrains a bunch of people to share repositories, but git is designed on the premise that you only "push" to repositories you, the sole engineer, are the total owner of. You then send a "pull request" or a "formatted patch" to other people you are collaborating with, who then have you setup as a "remote" (likely with a "tracking branch"), and then they pull from you.

However, just in case you (or whomever is reading this) really don't care and just must use git this way (with a single centralized repository shared between multiple collaborators), as of 1.6 they added some configuration variables "recieve.denyNonFastForwards" and "recieve.denyDeletes" that cause the server to reject destructive activities. Alternatively, you can install custom hooks that provide this kind of behavior only for some branches, some users, or some other specific circumstances (maybe only on Tuesday ;P).

(One last thing: what you wanted to help you undo what you did was "git reflog", for future reference. Unless you manually override it, git actually stores recent--maybe 30 days worth of?--fifth-dimensional history, allowing you to see what you have been doing as you manipulate the fourth-dimensional timeline, and to allow you to somewhat-easily revert mistakes you may have made.)