The Real Difference Between Git and Mercurial
xentac.net
xentac.net
Usability preferences can differ greatly by person. Another example is information retrieval in a personal database or help system. Some people prefer going through a search engine; others find a directory-based approach more intuitive (and forcing one approach on the other group does not improve productivity).
Similarly, having a unified set of tools for all kinds of version control problems is not necessarily an unalloyed good for everyone. Dealing with persistent history does not necessarily warrant the same approach as dealing with work-in-progress changes. For some users, it may be easier and better to consolidate both problems, for others, it can be more productive to keep them separate.
The Mercurial designers, for better or worse, have decided to separate persistent history changes from local work-in-progress changes, the latter being done via Mercurial Queues. That has the disadvantage that you need to learn a separate set of tools; it has the advantage that unfinished stuff does not pollute your repository's history and that you can tailor both sets of tools to their respective needs (whether they are in fact properly tailored is a different debate).
I suspect that, similarly, Bzr's one-directory-per-branch approach (inherited from Arch) is an easier mental model for some users to deal with than either git's or Mercurial's DAG-based approach, despite many git and Mercurial users not understanding the appeal.
Incidentally, both examples that you list (git stash and git commit --amend) are easily handled by Mercurial Queues. You don't need several separate extensions. (Obviously, some people do prefer special extensions because they reflect their mental models better or optimize common workflows.)
No, no, no. Let's get this myth out of the way that Mercurial Queues can somehow be part of a modern revision control system. Mercurial Queues are a simple stack of DUMB patches. The only reason why they are used is that often that is all you really need.
But the moment you need any kind of advanced functionality, such as say, something unimaginable like rebasing a Mercurial Queue against an upstream change that conflicts, you are suddenly dealing with tools that are no more advanced than diff and patch, and most certainly don't support any advanced operation on the patches that they juggle. I heard some modern tools like CVS support an advanced operation they call "merge". I'm still waiting until someone implements a usable version for Mercurial Queues.
So please, the moment you use Mercurial Queues in an argument, you've lost. Mercurial Queues are diff and patch in a fancy packaging, but with all the limitations of those. If your revision control system needs them to have the same functionality as another, you've lost.
The dirty secret is this: Mercurial users use Mercurial Queues because Mercurial got branching wrong. It's as simple as that.
In a way, the Git vs. Mercurial debate feels like vi vs. emacs all over again. Hardcore emacs users never quite understood the appeal of a modal editor; hardcore vi users couldn't quite understand how people lived with an input model that constantly moved their fingers off home row.
Emacs and vi both have their strengths and weaknesses. I've used both over the years sometimes trending to one or the other depending on the circumstances. As I've gotten to know both better, I understand the relative strengths better and know when it makes sense to use either. They're both good tools, and will both keep big user-bases for the foreseeable future.
Can I say the same about Mercurial and Git? That's a resounding NO.
I can accept that some holy wars can't have winners. But we should also be willing to accept that some tools can be just better than others.
With MQ, and especially with a versioned MQ directory, you have a great workflow for review-ready patches. And review-ready patches are what you are creating, after all, in most large projects: You do some work, you refactor that work N times, then you submit it for review, then you repeat that M times until it passes review and you push it to trunk.
With MQ, you can see the entire history of your set of patches. If you have a queue and you refactor two patches into one, you can go back in history in the versioned MQ dir to see what things were like before that. That is useful, because again, the "product" you are creating is a set of review-ready patches. So versioning the patches makes sense.
I understand that you can use git branches very effectively - I use git myself, not mercurial. However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten.
Rewriting history is great - you don't want to submit for review a huge list of patches that include bugfixes as you were working. You want to submit the final patches. But what if you do need to look at the state your work was in the past, before you rewrote history?
Mercurial Queues are bolted onto Mercurial and you can often see the cracks. Merging is my pet peeve which I've already mentioned. I think it's not controversial to say that it's a pain? I think that, in true Mercurial tradition, there's an extension in development for it now...
So why do we need to deal with this bolt-on and the resulting pain? Because Mercurial branches aren't good enough, or at least can't adequately support the workflow people need. Compare the amount of Mercurial users using mq to the amount of git users using quilt or equivalents.
I don't disagree with the abstract principle of operation of Mercurial Queues. I disagree with Mercurial as it is.
However, if you use git to rewrite the history of your branch as part of your development process, AFAIK there is no way to go back in time and instantly see what your branch looked like at time K in the past, because history has been rewritten.
1) It may be possible to do this with reflog. I don't know for sure because I haven't needed to do this yet. (I think the main problem is that by default reflog purges old history at some point)
2) You can simply create more branches as you go. i.e. replace qcommit by git checkout -b etc. Then push the final ones.
But git branches also have pain points. The only way to save history from before you rewrite history is to save branches, as you mentioned - but doing that manually every time you rewrite history is a pain.
However, that history can still be very useful: You might hit a variation on those bugs later, and seeing the original unrewritten history can help a lot in refreshing your memory on what you did there (and it can be even more helpful for someone else getting up to speed on the code trying to fix that bug). Losing the history after history rewriting isn't a good thing.
In reality, 'rewriting history' comes down to things like:
* Creating a commit, then amending the commit message.
* Rebasing all of your current changes on top of a new version of master (basically re-applying all of your commits/patches on top of master).
* Fixing a typo creating a commit, and then squashing that into the original commit.
(Note: That these operations all happen on topic branches prior to being merged into master. Once you merge into master, or just publish for public consumption, then you should not be rewriting history at all.)
From my perspective, the view that git is useless because the ability to rewrite history means that valuable information is being lost is an extreme overreaction by people without much (or any) git experience.
If you want to hold this view, you should have rational examples of workflows where people will lose valuable information just as a matter of course.
With your MQ workflow, you can only ever do this for your own patches.
I've done this when I was submitting patches to a large git based project (perl5). The trick is to to the rebase and then re-tag your old branch. That way the old work is there if you need to reference it. Since it has a real live tag, it will not get garbage collected.
This is incorrect. "hg rebase" is more advanced and smarter than diff and patch. Also, people arguing against Mercurial seem unaware of "hg collapse" which allows rewriting history in a way similar to git.
(However I would probably not use hg rebase on Mercurial queues, which are meant to be managed by mq extension commands.)
I think most of the git vs. mercurial debates are non-productive because proponents of one tool don't know the other tool well enough to argue against it.
You hit the nail on the head there. I wouldn't claim at all to know git well, despite having used it in numerous projects. On the other hand I felt like I "knew" Mercurial from the moment I picked it up. I've never written code to work around a problem (as the article suggests), and typically on the few occasions I've had problems I've remedied them by using Mercurial commands I already knew without even needing to look up documentation.
Opinions are clearly divided between two tools that perform the same task in very different ways. You can't please all of the people all of the time, long may both continue. More productive for everyone in my opinion would be ensuring bridge projects like hg-git become first-class citizens of the DVCS world.
You completely contradicted your own claim already.
This is exactly what I'm complaining about: Mercurial Queues are diff and patch. And you need Mercurial Queues for decent Mercurial workflows.
I think most of the git vs. mercurial debates are non-productive because proponents of one tool don't know the other tool well enough to argue against it.
I use Mercurial extensively and on a daily basis, so I think I'm qualified to talk about it. People who claim the complaint is invalid should do Mercurial users a favor and point out a workflow that avoids the issue. I'm still waiting (and manually merging all my patch queues whenever I get a conflict in a topmost patch).
Try this workflow.
The popularity of GitHub has made using Git a bit of a no-brainer, in the literal sense - a lot of Git users never really thought about the decision, they just needed some code from a Git repo and picked up Git along the way. I just don't see where people would be having the same experience with Mercurial. I've picked up several books recently where Git was taught in the first few chapters as a necessary precursor.
It appears to me that Git is the new SVN, the new version control tool that we're just stuck with whether we like it or not. I can think of much worse things.
That's not entirely true, in the sense that popular editors tend to have more extensions, syntax highlighting for more languages, auto-completion, etc... That helps draw in more users.
I just don't see where people would be having the same experience with Mercurial.
Well, there's bitbucket. IIRC some programming language communities have standardized on even more off-mainstream VCS.
But yeah, on the whole Git got an advantage in users somewhere along the way, and that's now self-reinforcing. It helps that there's no competition that's obviously better.
It is possible that that is true, but I'd want a stronger backup. Making no negative comments about git at all sets off very strong alarm bells for me.
If you give me some examples, I can probably roll them into a followup post later on.
That said, I really enjoyed the article. As a hardcore git user, I've occasionally skirted the edges of Mercurial (mostly just by poking at Golang) and always been confused at some of the stuff I saw. I knew Mercurial branches were more permanent than Git ones, but I never realized quite how permanent they were.
Git doesn't give you access to its functionality but instead gives access to its data model. Stashes are just references, commits are created or destroyed at will, notes are just objects that point at commits and are stored in a different set of references, etc.
Git itself is a bunch of scripts that wrap (lower-level) git tools. For example git's "native" `git rebase` command is a shell script:
https://github.com/git/git/blob/master/git-rebase.sh
You can create your own commands simply by putting a script called `git-whatever.sh` in your path, e.g. git svn-abandon:
https://github.com/nothingmuch/git-svn-abandon
I don't know hg's extensions, so perhaps I don't know what I'm missing, but I have no complaints about git's extensibility. It allows editing of its entire database and all branches (I've been able to convert SVN repo and re-create all merges, change authorship and dates of commits) and has hook scripts that can intercept and customize important actions in the workflow (I've been able to build non-trivial website deployment automation using git as a base).
The author makes a point that git's more transparent approach makes certain things easy to implement and consistent. To reiterate his example, stashes are just objects in a place where they won't be found by default, but they still work with everything because there's no magic.
The second example shows that git trusts that the user knows best what to do. If you want to reset a branch to a certain commit, git allows you to do it, and because the data model is not hidden git can simply expose the needed operation (reset branch pointer) as is.
For the most part, git has neat porcelains for most operations nowadays, but the UI is sometimes a bit weird because it started off as nothing more than a set of tools to manipulate a DAG of content on disk. In my view this ended up becoming one of its strong points in comparison to other DVCS.
Had the post been called "An advantage of git over mercurial", I would have placed a much lower requirement.
The negative here is that A) git user has to know about all the tools, which takes a long time, and then solving the issue requires quite a bit of thought.
That's one of the problems about git is that as a result of the massive flexibility there doesn't seem to a "standard" way to do things, even basic things. Each org has to develop their own processes which is annoying and difficult for new people in the org.
I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.
Commit Often, Perfect Later, Publish Once: Git Best Practices https://gist.github.com/1540906
just? Wtf is HEAD@{1} ?
That might be simple, but as usual, only if you know a lot about git.
As a casual git user this annoys me; Even when doing basic stuff I often have to read a long blog-post about how git works internally. I can't remember having this problem when I was a casual Mercurial user.
You can check this yourself:
git show stash@{0}
You can also see this visually with "gitk --all".
all the other technical gizwangs can be debated by propellerheads till the cows come home, but the user experience is quite plainly better in hg.
flamewar goes here ->
However, equating that to the user experience is short-sighted. The user experience is also how well the tool works and fills the needs of the user. It think it's very controversial to state hg is better there (this is a polite way to say you're completely wrong).
I always start googling and hoping there's a stackoverflow question about it that has an answer that I don't get.
Mercurial: there's an extension for that!
Git: you can fix that just by adding --foo bar:buzz --derp herp to the commandline lol RTFM
I suppose git's tree objects could point to the empty tree to record an empty folder, but most of the git code is comparing file blobs not trees.
How do you get around this in mercurial?
Same (with a .empty or .keep file).
I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a commit". Creating an ephemeral commit is precisely the perfect solution in Mercurial! Do it, then all regular Mercurial commands (log, diff, etc) will work to manage it. To get rid of the temporary commit later, simply "hg strip" it. It will remove the changeset (and all its children, if any) from the history (a backup will be made in .hg/strip-backup). hg strip is part of the built-in mq extension.
Also, a simple solution to the poster's last complain (re-doing a commit while keeping history of the original commit) is as follow: let's say you are at revision A. You commit B. You realize you screwed up. So you go back to A: hg update A. Then you revert your working directory to the state of B: hg revert --all --no-backup -r B. Then you make the changes you forgot, and commit again: hg commit.
Having it as a real commit is an issue when you want to pull upstream for example. My solution would be hg qnew stashname, but I already ranted about the limitations of MQ in another thread here.
The two hg commands you mentioned are summed up as one with git: git reset --soft HEAD^. Then if you commit B' but ever want to go back to B, you could do git reset --hard HEAD@{2}
You can easily switch your working directory to one of them: hg update B or B'
You can easily throw away the one you don't want to keep: hg strip B or B'
If you are, can you explain what happened (and perhaps save our asses?)
In git, if you rewrite history, you lose information - you can no longer see what things looked like before you rewrote it.
Disclaimer: I use git myself and prefer it. But the hg and MQ bashing in the comments here is unfair.
I agree with Scott's assessment: it's really not that huge a deal if your using Git or Mercurial; they're very similar--it's using a distributed version control system that's a huge deal. Many many places are still locked into old school, centralized systems that make collaboration much harder than it is using Mercurial or Git.
While in mercurial native branching, you are allowed to get multiple heads in one branch, which from one point of view is frustrating, but from another is natural (since you really were both working on the same branch at the same time).
In Git they tried to solve this problem by origins system, but now, when I worked with both, I find mercurial branches to be the simplest concept that is easier to explain than git's origins.
The only big problem with mercurial branches is their speed, but I think that it can be solved (algorithms are not so complex to make it fast).