I am not an idiot for disliking git. Neither are these people:

http://blog.schwern.net/2013/02/28/git-text-adventure/
http://ventrellathing.wordpress.com/2013/01/25/git-a-nightmare-of-mixed-metaphors/
http://stevelosh.com/blog/2013/04/git-koans/

That git has an absolutely horrid CLI is a well-recognised fact. I was just one of the first ones to blog about it. :-)

I’ve been firing rounds pretty madly with git for 2 years now and I have yet to hit my feet (or lose any data). I did manage to lose a reference to a commit a few times. I wanted to use git reset –hard and –soft as a hamfisted technique for editing history. So I dug myself a hole in my scratch repository. At the bottom of the hole, I found git-reflog, and brought back my test commits easy pie. I made sure I knew how to climb out of the hole before I started using git-reset on important repositories.

I once walked into an irc channel and they told me to run “cat /dev/zero > /dev/sda” and I did it. I mean, cats are cute and don’t sound like delete at all. I didn’t want to admit I was an idiot, instead I said that cats are stupid.

Actually, that never happened, I just didn’t want you to feel like you’re alone.

I don’t know anything about hg. I have the feeling it is feature-wise comparable to git. I am, however, absolutely irretrievably in love with git because it is *SO*MUCH* better than rcs, cvs, or svn (and don’t trashtalk them — rcs is a million times better than “cp foo.c foo.c.bak”). I just got exposed to bzr for the first time, which I also thought was feature-comparable to git. Oh god, my hatred for bzr overflows. You know the tutorial-approved technique for branching a launchpad bzr repository winds up making a completely new copy of the history on your local computer. So then you have two complete local copies of the history, one that you can sync with the upstream trunk, and the other which is only good for your branch. There is a way around it, but it is an advanced topic instead of the regular advertised way of interacting with the thing. Git fucking rocks.

Git is quirky, inconsistent, and It can be very complex to do things that aught to be simple. While the foundation of git is very good, there is a lot of poorly thought-out and badly documented cruft on top of that.

Given that hg provides most of the same feature set, is extensible, safer, better documented, almost as fast (in spite of being written in python), and orders of magnitude simpler and easier to use, I think it’s clear that hg is for now the superior product. I will start using it!

If the git developers wish to create a really great quality product, they need to take a step back, wean themselves off the coffee and crack, take a deep breath, and create a totally new front-end which is simple and sensible. They should consider the feedback, and learn from their experience with git version 1 “chaos”. It would not hurt to cooperate with some people who are expressive and literate in the English language!

What is plainly false is that the reflog is append-only. There exists an explicit git reflog expire command that also deletes data from the reflog. Another git self-destruct button hidden in plain sight. Not to mention that since the reflog is simply metadata, the data it points to can vanish with time (can be garbage collected), making the metadata pretty much useless.

Your concerns that I am wasting my time, a simple hg fanboy thinking in hg terms (I think I have gotten quite good at understand what git does and why… and I still think it’s a horrible design… plus I have some working knowledge of other DVCSes like the aforementioned bzr and darcs), and that I can avoid git… I have already addressed in another blog post. I have more blog posts on this topic forthcoming.

It is unfortunate that we must appear as adversaries to each other. This is precisely the opposite of what git is supposed to foster: collaboration. Instead we are arguing over its (de)merits when we could be working together.

You come at Git with a Mercurial perspective. That’s fine, but please refrain from bashing Git whenever it does not behave like Mercurial, because it is *not* Mercurial, nor is it trying to be. Git provides you with features that Mercurial does not have (and vice versa), and Git comes with shortcomings that mercurial does not have (and vice versa). That is how it goes, everywhere. Don’t waste your time ranting about it. If you want Mercurial, use Mercurial. If you want Git, use Git. It’s as simple as that.

Yes, that metadata can be reconstructed from the reflog, with some work and some luck, as I later learned.

But this is a huge surprise for me. I didn’t even *consider* that a VCS could remotely *delete anything*. By comparison, all hg remote operations are append-only. I believe the same holds for bzr and darcs, but correct me if I’m wrong. You can’t delete any data with hg, not even metadata, with push and pull operations (unless you explicitly install server hooks in the server to do so after a remote operation).

This is a pretty dumb git design, I think. Allowing deletion of any data, including metadata, is like having a big red self-destruct button in your computer in case you ever want your computer to blow up. And don’t tell me it was my fault for not reading the label on the self-destruct button. Why would my laptop even have such a button?

Let’s start at the front. –mirror is a command to mirror a local repository, meaning that it will remove references remotely that have been removed locally. That is a feature.

What you wanted is git push origin –all, or git push with an appropriate refspec, or the push.default setting (man git-config).

As to getting your data back: you only deleted references, or pointers, to heads. The heads are still there. You just need to find them. The ways to find them are multifarious: if you find a SHA-1 in your scrollback, you can use that, e.g.

git branch recovered

Else you can make use of the reflog (man git-reflog), and if all else fails, use git-fsck to reconnect dangling heads.

Git will not delete any data, unless you explicitly tell it to (git-gc). Git usually won’t even let you juggle refs, but you can do that. If you drop the ball, just pick it up again and keep going. Never panic.