It's funny to see how the whole world concentrates on this Git thing, while there is a treasure trove called Mercurial.
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.
The ease of use is a big thing for me. I find Git a bit arcane -- it's better than it used to be (around the Hg 0.9 era), but it's still quite bad.
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.
> Git will let you blow away a month's work if you mistype a command.
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.
I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.
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?
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.
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?
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.
Completely agree. Furthermore, I'm able to keep C and Common Lisp and most of Javascript and a bunch of other languages and Mercurial in my head (brain cache) so I rarely have to ask somebody how to use them.
But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.
To be frank, I've no interest in selling anything so don't need a sales technique. To be franker, I think the OP was talking crap. No-one loses a month of work and doesn't think to get advice on how to fix it. It's just a stupid "git is bad" story.
Have you tried to operate an excavator? That thing is complicated compared to a car... But you know what? That is specialist tool. If you cannot operate with specialist tools you should not get a job of a specialist.
I'm quite adept at driving an excavator. I can pour wine out of the bucket of an excavator. It's quite easy with practice because muscle memory kicks in.
But if excavators were as hard to use as git, I'd never have mastered them.
I wouldn't say "programmers who use version control" are a group of people who would qualify as "specialists". Especially since all programmers should be using version control. It should be a fundamental skill necessary to entering the field.
Fuck that guy. Seriously if someone is in silo mode for a month I am going to fire that guy.
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!
> I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.
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.
I can tell you that it is in at least one use case that I've hit. If you have local uncommitted changes to a file, and then run `hg revert file` to undo your changes, it creates (by default) a ".orig" backup. The equivalent git command (`git checkout --hard` or something?) will just throw out local changes with no takebacks.
> every commit you've made in the past month is saved in the reflog
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."
Just in the case you didn't know, you can view the reflog with `git reflog`
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.
> Git will let you blow away a month's work if you mistype a command.
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.
I've never worked at a company with protected branches... even though it's best-practice. "Because some day someone might need to push to master to do a hotfix".
So I have a local git push hook which blocks master pushes :)
It really is. Sure, it is an issue that it's the same subcommand as you use for many other things (which is being worked on with git switch/restore), but there is no other context where you'd do `git checkout .` if it wasn't your direct intention to get rid of changes in your workspace.
At least on Windows Mercurial doesn't support filenames written in various languages. Git does. So Mercurial was made for one billion people while git for the rest 6.5 billion of us.
What does "written in various languages" mean? Mixing multiple legacy encodings in one filename? Unicode filenames work fine on Linux (I just tested it with Chinese) and I would be very surprised if they didn't on Windows.
The problem, as I understand it, was filenames were read and written as bytes. That's fine if everybody is on the same platform but it doesn't always work when moving between, for example, Linux (UTF-8) and Windows (UTF-16).
Hm, the Mercurial wiki does mention that's it was/is a problem on Windows.
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).
Well yes and on Windows they are a sequence of 16bit values, not utf-16. My point was the encoding of filenames differ. So you can't do a byte-for-byte copy and expect the same results across platforms.
As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.
IMHO: Because Github just came at the right time for a free "no strings attached" project hosting solution when Sourceforge decided to become evil. That was the reason why I switched to Github anyway.
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 ;)
It’s even more specific than that. GitHub chose “free public repos, paid private repos” as their business model and git as their DVC. Bitbucket chose the opposite.
GitHubs model is incredibly more viral and thus git won (sadly IMO).
* 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
> Github had a stronger association with open source than Bitbucket (dunno why though).
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.
As others have mentioned before, one possible reason could be performance, git commands work near instantaneously even for very large repos, perhaps mercurial was not able to offer a similar experience.
> * 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
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.
I used both at the same time at work for about 2 years, and mercurial was worse.
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.
Linus Torvalds made it. That at least got me to look into it. Then saw it was better than svn and never looked back. Or sideways, so I missed mercurial.
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.
Many will not admit it, but git is just better.
Back in 2008 I made a presentation about DSCVS where I introduced git, mercurial and bazaar, and my advice for fellow programmers was "use git".
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.