Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.
I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.
Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.
I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.
Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.
Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.
What's the command to mistype?
I can't imagine having a month of work on a local machine that hasn't been pushed anywhere so it has to be something about pushing.
Fortunately, that can always be undone with another command
git checkout .
?It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.
Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.
Management asked "what if you do that with Mercurial?"
Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can.
TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.
Was "asking someone who knows how git works" on your list of things to try?
What about "learning how git works"? Was that on your list?
Frankly, you don't seem to have been trying very hard to get this work back.
I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76
But if excavators were as hard to use as git, I'd never have mastered them.
If I can make an analogy.
There's little love lost on HN for C++. Anytime people mention C++ (possibly even here in this thread) people come out of the woodwork to talk about how hard it is to use, how it has too many features, blah blah.
I work in C++ every day. I don't think it's that hard.
When I have a question, I walk over and ask Chandler Carruth and Richard Smith. They are happy to help me debug my templates. Richard is the editor of the C++ spec, and Chandler is a well-known speaker, look him up on YouTube.
Over lunch we talk about new features of C++, we rant and gripe, and I learn.
Most people do not have Chandler and Richard in their life. Knowing them and the other experts on my team is a huge privilege. So when someone complains that C++ is too hard (wait for it, someone is going to do it here in this very thread...), it would be pretty insensitive of me to tell them that they should just ask someone who knows how C++ works.
Most of us in this thread do have someone in our life who is good at git, who helped us get started, and who saved our asses when we initially got stuck. Maybe that person isn't with us IRL, maybe that person is "just" a message board or IRC channel where we know we're welcome. But this too is a privilege.
If you've ever had trouble with anything and not had someone you could ask -- be it with C++, or real analysis, or whatever -- then I'd say you shouldn't throw stones at someone whose "whatever" happens to be git.
But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.
Someone posts that they'd tried to join two strings in C++ and print the result. And they couldn't figure out how to do it; they would keep losing the second string. So, they gave up and changed languages, losing a month's worth of work.
Would you think that was reasonable, because they didn't have Chandler Carruth and Richard Smith available to help?
The thing I object to is judging them at all.
They're not my coworker, someone I have to rely on and therefore might be annoyed if they're unproductive or whatever. They're a random person on the Internet who rather humbly admitted to making a mistake out of ignorance.
Our "Git expert" was the one who blew away a month of work.
Mistyped as "git reset --hard HEAD~n"? git-revert is usually pretty nondestructive…
Don't you have backups? The companies I worked for had backups for all the home directories, so if I deleted something I could ask the admins to restore it.
If there are no central backups I would sure as hell set up a local backup, so there are more than one copies of my work in case something goes bad.
He is doing either some dangerous changes, which is not acceptable OR he is doing something that could be walled off by feature switch and integrated with at least weekly commits.
If it was some manager that told him to do that, fire that manager too!
...so you thought you lost a day's or a month's work, you didn't actually lose it.
You could just revert your revert commit, or check out an earlier revision.
I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."
From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.
No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.
So I have a local git push hook which blocks master pushes :)
I don't know if that's still an issue.
As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.
I was surprised because we've been using it for years at work, sharing repositories between Linux and Windows, and we have never been bitten by this. Maybe the latin-1 subset of Unicode works? Or all the files we worked on just happened to have ASCII names (despite us being mostly non-Americans).
It's still probably slower for huge repos (I havn't checked), but I doubt it will bother you much nowadays.
I used Hg before Git professionally, because when they were both new, Hg had _much_ better Windows support.
That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.
After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.
Nobody expected that Github was essentially a Trojan horse ;)
GitHubs model is incredibly more viral and thus git won (sadly IMO).
i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.
Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.
I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.
* Bitbucket provided unlimited free private repositories and they were exclusively Mercurial. Github had limits for private repos.
* Google evaluated both and preferred Mercurial for code.google.com http://www.saturngod.net/articles/dvcsanalysis-support-analy....
* Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln
Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is
* git was strongly associated with Linus so it won that crowd handily
* Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
Maybe because it was bought by Atlassian.
Nope! Bitbucket had the "free private, paid public" model from the start. IIRC, Atlassian actually changed the model to allow unlimited public repositories after they purchased Bitbucket. It's possible that if BB had started with this model, they'd have been a much stronger competitor.
Early on GitHub gave out free public repositories, but Bitbucket gave our free private repositories. Working in public is aligned much more closely with open source than working in private is.