This fake interview is pretty funny:
"Linus: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd."
http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...
tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.
I have to disagree about the index, though. I use Git every day, and i'm still struck by how pointless the index and the idea of staging is.
Ditto rebase. The routine use of rebase still seems completely wrongheaded to me. Mercurial's convention of preferring merges is better, and the last few years' developments around safe evolution of history really show rebase up as the misconceived hack it is.
Mercurial got 'commit --amend' a long time ago, but even before that, it had 'rollback', which undoes the last commit, leaving the working tree untouched (that is, with the state it had in the commit), so you can make your fixes and commit again.
I'd entertain the argument that Git won because it was better if even a handful of the people who now use Git had learned both Git and Mercurial and made an informed choice between them. That simply does not appear to be the case. Git got ahead because Linus invented it, and won because of GitHub.
I find it amazingly useful. The staging area is for building your commit. I always ever use -p (ie., "add -p", "reset -p" and "checkout -p") and use it to construct the commit out of parts.
The way I work, I split my current work into multiple commits. I may have implemented a feature, fixed a bug I found along the way in the same file, and updated the readme with something unrelated; those are three separate commits. I do "add -p" to pick the fragments, and when I'm happy, I commit. Repeat until repo is clean.
Sometimes, my current work results in a whole bunch of such commits. Sometimes I have to split part of my current work into a separate branch. Again: Stage stuff, stash -k, checkout new branch, commit as a WIP commit, go back, unstash.
Darcs has "record", which is like "add -p" except it also commits at the same time, and back when I was using it, I remember hating the fact that it required that everything had to be recorded in one go. Git's incremental staging area is much more pleasant because you don't get stressed out by the impending commit that is looming over you.
One thing I really like about git is that it lets me be mindful of my actions in a way that hg didn't seem to encourage. In return, it gives me what feels like True Power to recover from _any_ mistake. Wrong branch? Accidentally merged (and pushed) my master branch? No problem, they're just bookmarks to commits anyways.
Mercurial, by contrast, felt Rather Convenient, with occasional chasms of despair if you strayed too far from the path. It's possible that my high opinion of Git is mainly from the fact that it forced me to learn more, but it really feels more flexible. I always have the right tool for whatever I need, and I know why and how to use them.
This is probably more a symptom of the fact that either your workflow doesn't require an index or you don't understand its value.
Either way, the index is by far git's more popular and used feature, besides branches.
I use Git on a daily basis, but I never understood it.
If I just want to commit a specific part of my changes, I just do it. It's nice to see which files are staged for a commit, but I also see them in the commit msg comments.
They're called "hunks" in git parlance: sections of the file that define a "diff". A diff on a file can be made of multiple hunks.
Very often, my changes to a file are a mix of "fixing a serious bug" and "minor refactoring" and "removing dead code". When the time to commit comes, git makes it trivial to separate all these changes in different commits so that each commit does one thing and one thing only.
I think you also underestimate the developer community (or may I overestimate them.) Regardless, my anecdotal evidence is that I did try HG and Git, and while I preferred HG when I first started evaluating them, as soon as I found out how to use Git branches, it was all over for HG. At work we currently inherited a project in HG and everyone that has to work on it complains about it. Some know Git, some are .Net or even old school CVS/SVN people (our VCS migration took a bit longer than it should have), but it doesn't matter. HG = hard to use for them, whereas Git make sense after getting over the initial hurdles. I see the same kind of path I took, where at first they are like, oh, Hg isn't bad, and then after using both, choosing Git as their preference.
Rebase is a hack? Rebase copies a series of commits on top of an immutable history at a certain point in time. This allows you to deal with merges a single conflict at a time, instead of dealing with all the conflicts at once with a merge. It also allows you to avoid cluttering your history with useless merge-commits when just syncing with another repo.
Merges have their place. I use them whenever I merge branches, using --no-ff so I can attach a "Fixes issue #77" in the merge commit message. Of course, before I do that, I sync the branch I'm merging into, then rebase on top of that (to have a clean merge). I might also rebase --interactive to clean up the commits of my branch, so that the history is as easy to read as possible.
Comparing rebase to rollback is wrong. Git has rollback (or revert) as well, and it's used for other usecases, like when reverting changes on a public branch (where rebase would fuck it up for everyone).
I'm sorry, but your comments make it sound like you don't really understand Git.
Not sure what you mean by 'deal with a single conflict at a time'. To rebase or merge, you will have to resolve all conflicts that merge/rebase produce, right?
It's easier to remember the intended behaviour when the code changes are as small as possible, and when you have a (hopefully) good commit message to look at.
If you are concerned about reading history, then a merge can give you more context regarding the commits. With re base, commits will jump between features. For example, You are looking at commit for feature 1, but the next series of commits are for a bug fix in feature 2. Next series of commits belong to minor tweaks in feature 3..
Regarding the "rebase, commits will jump between features" part: that really depends on how you do things. On my projects, we use git flow. In such a scheme, every branch you would rebase, belongs to the same feature or bugfix.
Not sure if I made that clear. But I was talking about the result of the rebase. Once you rebase, all the commits that were in different branch ends up being back to back, and hence become interleaved...
I can't tell you how many times I've shot myself in the foot accidentally committing stuff to svn when I just meant a single file.
This is quite subjective. A more probable reason is that git is popular because of github..
And once git gained some popularity, people started viewing other DVCS as inferior because they were doing things differently from Git. For eg, the branching in Mercurial. People are appalled when they see how named branches can be done in Mercurial. Without going into any thought or reflection on how Mercurial's named branching can be useful in certain situations, they call it braindead. But actually git's branching is quite simple and less powerful than the methods offered by Mercurial. Less powerful, because Mercurial offers multiple methods to make a branch so that you can use the right one for a particular situtation. Note that this actually asks for more experience from the user. He needs to have experience with using each of these methods and should know how each of them may be useful in the future. It also stores more metadata and tools like revset which lets you to build powerful queries. So in that sense, Mercurial is also more complex than Git. But that is in a good way and unlike git's, it is not the complexity that gets in your way.
So in short, I think git is actually quite simple than Mercurial, but hides that simplicity behind a complex interface with non-intuitive naming and weird combination of flags and stuff. This causes the 'Aha' moments when one can finally see the simplicity that hides behind that interface, which trigger a huge release of Dopamine and prompts the user to write his own set of Git revelations that (used to) flood the internet, which in turn increases the popularity of Git...
My team started using Mercurial a couple years before Git but eventually migrated over because in practice Git was less surprising and nobody had lost data using it.
Or rather (in many cases) how good it makes people feel to use and tell other people they use something incredibly complicated, whether they actually understand it or not.
I'd venture that a fairly large amount of the people who use git don't really understand it fully, they just understand some very small subset of what they picked up from whatever "best git flow" website or book they happened to read.
Lest anyone think I'm being elitist here, I'll come right out and admit there's a ton of stuff in git I've never bothered to really understand. I'm okay with standard push/pull commits, stashing and rebasing, but I still kinda think of these things as sort of interpretations of concepts I'm used to from older non-DVCS systems, I don't "grok" git, not really -- never really bothered since I find source control systems incredibly useful but not inherently interesting (to me personally).
All that said, I don't use git to show off, I use it because virtually everyone else does and there is a certain pragmatic benefit to going with the flow on something like that even if I think it is overkill for a lot of the projects I need a VCS for.
https://static.googleusercontent.com/media/research.google.c...
Your idea (my interpretation) that the industry mostly consists of people having productive discussions seems more off base. Yes, that's the way it should be, and usually is on HN and similar forums, but out in the larger real world, arrogance, superiority, etc are the order of the day.
If you want to make such claims, I'd love to see data backing it up.
[1] https://www.openhub.net/p/compare?project_0=Mozilla+Firefox&...
It is of course possible that performance follows a saddle like curve (or hump depending on how you look at it). For up to some size, git is faster. But at much larger ones a different algorithm wins out and hg could be end up being faster.
The main problem is that mercurial never got real branches, which is git's wheelhouse, forcing gross things like the "forest" extension (which I believe is now unmaintained). Maybe it's gotten better since then, but this was about 3-4 years ago.
The way I see it, git has all the powertools you'd need, and you don't have to use them most of the time, where as mercurial feels generally stripped down to be "easy", and when you want to do the hard things, it's not so good at it.
One of those examples might be something like grafting a repo into another repo at a arbitrary root, or some of the tricks you can do to edit previous commits (say if you mispelled your username all the way down).
My main point of switching originally was when I believe it mixed up a lot of commits in a merge and lost some changes. I also recall hearing about a patch for predictable ordering in diff output being rejected.
git's really gotten TONS better -- way back, I would say mercurial was easier to use, and git really excels at branch based workflows which at this point I can't live without.
Of course, a worse thing from having to work at a mercurial shop after loving git is having to work at a SVN shop :)
What we've learned is that these two things are actually liabilities.
git is a good example that the syntax of the command line is of no consequence. git's CLI is notoriously horrendous and bizarre, yet it didn't stop its adoption. And this is a problem that's easily worked around by creating tools (graphical ones and also porcelaines) around it.
The fact that Mercurial is written in Python has a big impact on its performance, and git is running rings around it as a result. When you run tens of commands every day, it adds up.
Strangely enough even git's initial hostility to running on Windows didn't stop its adoption.
git's features and modeling of source control system is so powerful and flexible that git became successful in spite of all these other aspects.
Frankly, I think it's silly to use any other source control these days: embrace git and get used to it because it's going to be around for a while.
This wasn't the case at all. In their early years, some operations were faster on git, and others, faster on Mercurial[1]. I don't remember any recent benchmarks, but early last year, there were reports of Facebook making Mercurial faster [2].
> Frankly, I think it's silly to use any other source control these days
You might get that impression if your work is centered around github, but I have friends who use enterprise-specific extensions on Mercurial that structure their workflow.
[1] http://draketo.de/proj/hg-vs-git-server/test-results.html
The bottom line is that a program written in C will always be orders of magnitude faster than a program written in Python. This is not news.
Yes, I am. And I gave a reference for it.
> Facebook forked it and managed to make it faster but they never released their fork so nobody can actually use it.
I invite you to look up the license that Mercurial is released under. And then I advise you read [3]. And why do you keep making these unsubstantiated claims?
> The bottom line is that a program written in C will always be orders of magnitude faster than a program written in Python. This is not news.
If we're comparing exactly the same algorithms implemented in both Python and C, C would usually be faster. But we are not discussing the implementation of simple algorithms. We are talking about complex software, with different architectures.
[3] https://code.facebook.com/posts/218678814984400/scaling-merc...
No, it doesn't.
You know why git won? HG was slow as molasses when they both showed up on the scene. That and git's branches are a dream come true. I think back then, an HG branch was a clone of the repo.
I can't figure out what sort of suffering people are talking about.
There are ways around it like hg-git, but they can't really hide the git underneath. We have to use git or be computer hermits.
Most of the git commands I use are about as straight forward and simple as they could be. If ever I manage to screw something up, the archeology commands I end up using are obtuse, but it's rare that I need them. And I'm glad they are there when I do.
If you are having to download 3rd party extensions, then that's a different problem.
I've somehow created a branch that couldn't be deleted. Instead of being really deleted it appeared in remote repository as some kind of a "tombstone".
I've tried to rebase, but to do that I had to fiddle with settings and enable plugins.
My impression was that Mercurial is a higher-level version of git, with the sugary layer doing things that I don't want.
The problem here is one of conflicting terminology. What Git calls a branch, no other version control system calls a branch. A branch in Git is really a moving pointer to the head of a branch as other VCSs would see it.
The confusion can go both ways, by the way. I.e. when a user who is used to another VCS expects a branch to be a persistent label for a set of commits and then discovers that it doesn't work like that for Git repositories and that your branches may "move" or "disappear" and don't even describe sets of commits but individual commits.
Except Git tracks history of the named branch in the reflog, and SVN (and others, I would guess) track it inside the repository. This is a huge difference for archeologists, but quite minor in practice from my experience.
Eventually, just less than a year ago, I bit the bullet and made the switch to git. What did the trick for me was a list of short aliases I copied from somewhere, tweaked and have been maintaining in my ~/.bash_aliases ever since. Some aliases are just shortcuts for super common commands (such as "alias gts='git status'") but others remove the burden of remembering what combination of commands and arguments make sense to me ("do i undo a change with revert, reset, checkout or something else? well it depends.."). I still can't claim I know git in depth but it's good enough for day to day usage.
Can you elaborate and/or point to an issue tracker that describes the problems?
The Windows malfunction may be more work than a reasonable person would want to bite off, but getting it to work on Linux should be feasible.
Mecurial is super easy to learn - there is no reason not to be comfortable with both.
Many times this. Git reflog is an extremely powerful feature to fix mistakes. Any git user should at least in base understand what the reflog is and how it can be used for roll-backs.
Git has git style branches which make it really easy to work on different things. Apparently hg added some of that later but it's not the main workflow
git also has a "staging area". You put things into the staging area and then commit. So for example the equivalent of "hg commit" in git is "git commit -a". The -a means "copy everything that's changed to the staging area".
The advantage of the staging area is it's easy to commit just a few files even if many have changed. It's even easy to commit just a few changed lines from a file and leave the other lines un-commmited.
There are other advantages I'm sure and I'm sure I didn't explain the branching one well. I can point out that I have repos with completely unrelated branches. One branch is the website, another branch is the docs, another branch is the source code, branches in hg, at least the default ones, are assumed to be something that will eventually be merged back. hg complains forever until you merge the branch back. git branches are effectively unrelated to each other, although by default git will track where it branched and if you happen to merge them where they merged. branches can be pushed and pulled to other repos or not, it's up to you.
Someone above said hg has bookmarks that are similar to git branches but I'd be curious if they're actually the same.
I've heard hg since then has added features that make it possible to have a more git like workflow but AFAICT it's still not the "recommended" at least not the default workflow which means I have no desire to switch back.
I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see.
That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.