5 ms·

The Real Difference Between Git and Mercurial

182 points by xentac 15y ago

yason 15y ago
I sometimes wonder that BitKeeper had allowed kernel developers to use it freely, none of git would have happened. Conversely, does anyone know what's going on with BitKeeper these days? Assumedly they can sell their commercial product to some markets but practically I haven't heard of BK once since git was announced. Potentially a big blunder on their part.
CJefferson 15y ago
This article seemed to start off well, but at the end turned into a 'Git is better because tools can edit the DAG storing state. QED'. 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.
- xentac 15y ago
  Fair assessment. This is where my bias towards git shows through. I use git and understand what it's capable of and why mercurial does it differently. The opposite isn't true. If you give me some examples, I can probably roll them into a followup post later on.
  - eridius 15y ago
    The piece may be improved by highlighting the fact that while Mercurial users have to write extensions to work around problems, the flip side is they _can_ write extensions to do things the built-in tools don't do. For example, the Golang project has an extension that integrates with their code review system. With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension (though it can frequently accomplish the same purpose). 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.
    - xentac 15y ago
      I guess the big difference is the level of interaction. A Mercurial extension has access to all the functionality that Mercurial offers: applying patches, creating commits, history walking, etc. But it doesn't really modify the underlying representation of that data (queues store their data in the working copy, for example). 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.
      - aredridel 15y ago
        Interesting. I've never considered that git doesn't give access -- it's always seemed right there to me, whether I want to tweak it by calling out to a git tool to do it, or doing it myself.
        xentac 15y ago
        It does, but instead of giving you a library/API access, like Mercurial, it gives you command line access. I feel as though one is a little more black box than the other.
        chrisrhoden 15y ago
        Please see libgit/libgit2
    - aredridel 15y ago
      Interesting. What's the difference to you? Git's extensions are shell (or whatever other language) tools is all, in my mind.
    - pornel 15y ago
      > With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension 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 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 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).
- chousuke 15y ago
  Is it necessary to find something negative in git if you want to highlight a limitation in mercurial? (That can admittedly be worked around with extensions) 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.
  - CJefferson 15y ago
    The title of the post was "The Real Difference Between Git and Mercurial". This implies to me that the article is about one, clear difference, which is the main distinction between the two. Had the post been called "An advantage of git over mercurial", I would have placed a much lower requirement.
- OmarIsmail 15y ago
  I think the author does say something negative about git, just doesn't say it in a negative way. "When a git user runs into a problem, they look at the tools they have on hand and ask, “how can I combine these ideas to solve my problem?”" 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.
  - gcp 15y ago
    I wouldn't mind some of the big users of git summarizing the "best practices" they arrived at in a nice presentation.
    - dmoney 15y ago
      For large projects, there is git-flow: https://www.google.com/search?q=git-flow https://www.google.com/search?q=git-flow I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.
      - lysium 15y ago
        github uses a different flow. This article mentions the issues with git-flow and describes the flow used at github: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
    - SethRobertson 15y ago
      Here is a document describing git best practices which has been liked by some of the most knowledgeable git users out there. Commit Often, Perfect Later, Publish Once: Git Best Practices https://gist.github.com/1540906 https://gist.github.com/1540906
  - gizzlon 15y ago
    another negative sentence: "you can just point the branch pointer back at the previous commit with git reset --hard HEAD@{1}" 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.
stevelosh 15y ago
I wrote an article with the exact same title but very different content almost exactly one year ago: http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ http://stevelosh.com/blog/2010/01/the-real-difference-betwee...
skrebbel 15y ago
Wait, Mercurial users start coding when they run into a problem with the tool? I always start googling and hoping there's a stackoverflow question about it that has an answer that I don't get.
- jonknee 15y ago
  I think the author was referencing hg's numerous extensions. In reality I think both git and hg users turn to Google when they get stuck (same for bzr, svn, cvs, and every other scm).
- gcp 15y ago
  That certainly reflects my experience: I have a problem... 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
  - mariusmg 15y ago
    Maybe somebody can add a extension to Mercurial that let's you use empty folders.....
    - xentac 15y ago
      Git and Mercurial both suffer from this "problem". Because manifests/trees must have contents (file hashes) to exist, you can't track an empty folder. 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.
      - eridius 15y ago
        Git's tree structure can certainly encode an empty directory, the problem is the index file can't.
      - pavel_lishin 15y ago
        In git, we solve this problem by sticking a .gitignore file in any directories we want to be part of the repo, but without the contents (cache folders, user-generated data destinations, etc.) How do you get around this in mercurial?
rbehrends 15y ago
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. 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.)
- waqf 15y ago
  At least one person's file created with vi can be edited by someone else using emacs.
  - gtrak 15y ago
    hg and git can indeed interop
__david__ 15y ago
A small nit about git stashes: they aren't stored in a special linear branch. Each stash is a little branch off of wherever you were when you created the stash. The only trick is that the stash commits are named something weird so that "git stash list" can find them and list them. You can check this yourself: git show stash@{0} Look where it says "WIP on {branch-name}: {hash}". That {hash} will be one of the hashes in the "Merge" header near the top of the commit. You can also see this visually with "gitk --all".
- xentac 15y ago
  You are correct. They aren't a linear history. In fact, the key is the @{#} syntax (man git-rev-parse). Each stash commit is a single commit pointed to by a ref/stash reference. Because of the reflog, we can see what ref/stash used to point at, that is @{1}, @{2}, etc.
  - __david__ 15y ago
    It's actually (potentially) more than a single commit. If you have a dirty index when you stash then that will also be committed along with your working directory changes. If you use the new(ish) --include-untracked option to stash, a 3rd commit will be added that has the untracked files in it. The main stash commit (that holds your working directory changes) is a fake merge of all the commits, just so there are pointers back to the other 2 commits.
k_bx 15y ago
I think that the real difference between git and mercurial is allowing multiple heads in the same branch. Everything else is just an API difference, but from high level point of view -- they're just trees if commits, that's all.
- tonfa 15y ago
  The real difference is the terminology: mercurial named branches mean something other than git branches (git branches are similar to mercurial bookmarks). Steve Losh's article explains that very well.
  - k_bx 15y ago
    No, I know about bookmarks, but still, it's all about multiple heads. In mercurial branches, if you merge someone's work on the same bookmark as you did, you get new anonymous head. That head gets it's bookmark lost, since bookmark can only point to one changeset, that's why this bookmarks mechanism fits mercurial not too good. 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).
Rusky 15y ago
The biggest advantage of Git's storage model is imo the reflog- I have irretrievably lost work to Mercurial Queues, and that's virtually impossible in Git.
- gcp 15y ago
  I really, really, really hate to write in defense of Mercurial, but you are aware that Mercurial Queues are versionable themselves, right? If you are, can you explain what happened (and perhaps save our asses?)
- azakai 15y ago
  If you version your MQ, you can never lose data in it. 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.
  - Rusky 15y ago
    When I used MQ, it was to modify history in a way equivalent to some of git's features. Versioning that defeats the purpose.
    - gcp 15y ago
      The MQ versioning repo is separate from the main versioning repo. So I don't see how one follows from the other here. You can perfectly modify history in the main repo and version that editing in the MQ repo. The main repo will look clean because the history editing is versioned in the MQ repo.
      - Rusky 15y ago
        Ah, that's good to know. I was not aware of that.
  - deleted 15y ago
    [deleted]
reinhardt 15y ago
Mercurial was my first DVCS so I'm perhaps biased but its API has always fit my brain better. We use Git at my current job but after a few days of trying to get used to it, adding shortcuts to avoid remembering the cryptic switches required to do simple tasks and finally screwing up in some merge conflict, I said the hell with it, installed hg-git and work happily ever after.
mml 15y ago
imho, as biased as a huge fan of hg can be, and someone who lives in git on a day to day basis, is that git has an actively hostile UI, mercurial has a great one. 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 ->
- gcp 15y ago
  I think the point that the UI of the default tools is better in Mercurial is entirely uncontroversial. 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).
mrb 15y ago
(I know Mercurial very well. I evaluated 5 or 6 distributed VCS tools and decided to migrate my employer's repository from CVS to Mercurial in 2008: 2GB of history, 150k files, 20k changesets, dozens of developers.) 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.
- lloeki 15y ago
  Will this preserve the original B? Is it easy to throw away B' and go back to B? (honest question, I know hg only superficially) 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}
  - mrb 15y ago
    Absolutely, it would preserve the original B. 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'
- gcp 15y ago
  I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a 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.
alwillis 15y ago
Even GitHub dude Scott Chacon (who does training on Git for GitHub and who wrote the book Pro Git) says in this podcast some aspects of Mercurial are better thought-out than Git: http://thechangelog.com/post/3445186374/episode-0-4-9-git-showoff-and-xbox-kinect-with-scott-cha http://thechangelog.com/post/3445186374/episode-0-4-9-git-sh... 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.

182 points by xentac 15y ago

yason 15y ago

I sometimes wonder that BitKeeper had allowed kernel developers to use it freely, none of git would have happened. Conversely, does anyone know what's going on with BitKeeper these days? Assumedly they can sell their commercial product to some markets but practically I haven't heard of BK once since git was announced. Potentially a big blunder on their part.

CJefferson 15y ago

This article seemed to start off well, but at the end turned into a 'Git is better because tools can edit the DAG storing state. QED'. 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.

xentac 15y ago
Fair assessment. This is where my bias towards git shows through. I use git and understand what it's capable of and why mercurial does it differently. The opposite isn't true. If you give me some examples, I can probably roll them into a followup post later on.
- eridius 15y ago
  The piece may be improved by highlighting the fact that while Mercurial users have to write extensions to work around problems, the flip side is they _can_ write extensions to do things the built-in tools don't do. For example, the Golang project has an extension that integrates with their code review system. With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension (though it can frequently accomplish the same purpose). 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.
  - xentac 15y ago
    I guess the big difference is the level of interaction. A Mercurial extension has access to all the functionality that Mercurial offers: applying patches, creating commits, history walking, etc. But it doesn't really modify the underlying representation of that data (queues store their data in the working copy, for example). 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.
    - aredridel 15y ago
      Interesting. I've never considered that git doesn't give access -- it's always seemed right there to me, whether I want to tweak it by calling out to a git tool to do it, or doing it myself.
      - xentac 15y ago
        It does, but instead of giving you a library/API access, like Mercurial, it gives you command line access. I feel as though one is a little more black box than the other.
        chrisrhoden 15y ago
        Please see libgit/libgit2
  - aredridel 15y ago
    Interesting. What's the difference to you? Git's extensions are shell (or whatever other language) tools is all, in my mind.
  - pornel 15y ago
    > With Git you can write shell scripts and tools that wrap git, but that isn't quite the same thing as an extension 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 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 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).
chousuke 15y ago
Is it necessary to find something negative in git if you want to highlight a limitation in mercurial? (That can admittedly be worked around with extensions) 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.
- CJefferson 15y ago
  The title of the post was "The Real Difference Between Git and Mercurial". This implies to me that the article is about one, clear difference, which is the main distinction between the two. Had the post been called "An advantage of git over mercurial", I would have placed a much lower requirement.
OmarIsmail 15y ago
I think the author does say something negative about git, just doesn't say it in a negative way. "When a git user runs into a problem, they look at the tools they have on hand and ask, “how can I combine these ideas to solve my problem?”" 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.
- gcp 15y ago
  I wouldn't mind some of the big users of git summarizing the "best practices" they arrived at in a nice presentation.
  - dmoney 15y ago
    For large projects, there is git-flow: https://www.google.com/search?q=git-flow https://www.google.com/search?q=git-flow I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.
    - lysium 15y ago
      github uses a different flow. This article mentions the issues with git-flow and describes the flow used at github: http://scottchacon.com/2011/08/31/github-flow.html http://scottchacon.com/2011/08/31/github-flow.html
  - SethRobertson 15y ago
    Here is a document describing git best practices which has been liked by some of the most knowledgeable git users out there. Commit Often, Perfect Later, Publish Once: Git Best Practices https://gist.github.com/1540906 https://gist.github.com/1540906
- gizzlon 15y ago
  another negative sentence: "you can just point the branch pointer back at the previous commit with git reset --hard HEAD@{1}" 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.

stevelosh 15y ago

I wrote an article with the exact same title but very different content almost exactly one year ago: http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ http://stevelosh.com/blog/2010/01/the-real-difference-betwee...

skrebbel 15y ago

Wait, Mercurial users start coding when they run into a problem with the tool? I always start googling and hoping there's a stackoverflow question about it that has an answer that I don't get.

jonknee 15y ago
I think the author was referencing hg's numerous extensions. In reality I think both git and hg users turn to Google when they get stuck (same for bzr, svn, cvs, and every other scm).
gcp 15y ago
That certainly reflects my experience: I have a problem... 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
- mariusmg 15y ago
  Maybe somebody can add a extension to Mercurial that let's you use empty folders.....
  - xentac 15y ago
    Git and Mercurial both suffer from this "problem". Because manifests/trees must have contents (file hashes) to exist, you can't track an empty folder. 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.
    - eridius 15y ago
      Git's tree structure can certainly encode an empty directory, the problem is the index file can't.
    - pavel_lishin 15y ago
      In git, we solve this problem by sticking a .gitignore file in any directories we want to be part of the repo, but without the contents (cache folders, user-generated data destinations, etc.) How do you get around this in mercurial?

rbehrends 15y ago

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. 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.)

waqf 15y ago
At least one person's file created with vi can be edited by someone else using emacs.
- gtrak 15y ago
  hg and git can indeed interop

__david__ 15y ago

A small nit about git stashes: they aren't stored in a special linear branch. Each stash is a little branch off of wherever you were when you created the stash. The only trick is that the stash commits are named something weird so that "git stash list" can find them and list them. You can check this yourself: git show stash@{0} Look where it says "WIP on {branch-name}: {hash}". That {hash} will be one of the hashes in the "Merge" header near the top of the commit. You can also see this visually with "gitk --all".

xentac 15y ago
You are correct. They aren't a linear history. In fact, the key is the @{#} syntax (man git-rev-parse). Each stash commit is a single commit pointed to by a ref/stash reference. Because of the reflog, we can see what ref/stash used to point at, that is @{1}, @{2}, etc.
- __david__ 15y ago
  It's actually (potentially) more than a single commit. If you have a dirty index when you stash then that will also be committed along with your working directory changes. If you use the new(ish) --include-untracked option to stash, a 3rd commit will be added that has the untracked files in it. The main stash commit (that holds your working directory changes) is a fake merge of all the commits, just so there are pointers back to the other 2 commits.

k_bx 15y ago

I think that the real difference between git and mercurial is allowing multiple heads in the same branch. Everything else is just an API difference, but from high level point of view -- they're just trees if commits, that's all.

tonfa 15y ago
The real difference is the terminology: mercurial named branches mean something other than git branches (git branches are similar to mercurial bookmarks). Steve Losh's article explains that very well.
- k_bx 15y ago
  No, I know about bookmarks, but still, it's all about multiple heads. In mercurial branches, if you merge someone's work on the same bookmark as you did, you get new anonymous head. That head gets it's bookmark lost, since bookmark can only point to one changeset, that's why this bookmarks mechanism fits mercurial not too good. 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).

Rusky 15y ago

The biggest advantage of Git's storage model is imo the reflog- I have irretrievably lost work to Mercurial Queues, and that's virtually impossible in Git.

gcp 15y ago
I really, really, really hate to write in defense of Mercurial, but you are aware that Mercurial Queues are versionable themselves, right? If you are, can you explain what happened (and perhaps save our asses?)
azakai 15y ago
If you version your MQ, you can never lose data in it. 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.
- Rusky 15y ago
  When I used MQ, it was to modify history in a way equivalent to some of git's features. Versioning that defeats the purpose.
  - gcp 15y ago
    The MQ versioning repo is separate from the main versioning repo. So I don't see how one follows from the other here. You can perfectly modify history in the main repo and version that editing in the MQ repo. The main repo will look clean because the history editing is versioned in the MQ repo.
    - Rusky 15y ago
      Ah, that's good to know. I was not aware of that.
- deleted 15y ago
  [deleted]

reinhardt 15y ago

Mercurial was my first DVCS so I'm perhaps biased but its API has always fit my brain better. We use Git at my current job but after a few days of trying to get used to it, adding shortcuts to avoid remembering the cryptic switches required to do simple tasks and finally screwing up in some merge conflict, I said the hell with it, installed hg-git and work happily ever after.

mml 15y ago

imho, as biased as a huge fan of hg can be, and someone who lives in git on a day to day basis, is that git has an actively hostile UI, mercurial has a great one. 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 ->

gcp 15y ago
I think the point that the UI of the default tools is better in Mercurial is entirely uncontroversial. 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).

mrb 15y ago

(I know Mercurial very well. I evaluated 5 or 6 distributed VCS tools and decided to migrate my employer's repository from CVS to Mercurial in 2008: 2GB of history, 150k files, 20k changesets, dozens of developers.) 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.

lloeki 15y ago
Will this preserve the original B? Is it easy to throw away B' and go back to B? (honest question, I know hg only superficially) 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}
- mrb 15y ago
  Absolutely, it would preserve the original B. 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'
gcp 15y ago
I don't understand the poster's insistence about wanting to perform an operation similar to git stash in Mercurial "without creating a 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.

alwillis 15y ago

Even GitHub dude Scott Chacon (who does training on Git for GitHub and who wrote the book Pro Git) says in this podcast some aspects of Mercurial are better thought-out than Git: http://thechangelog.com/post/3445186374/episode-0-4-9-git-showoff-and-xbox-kinect-with-scott-cha http://thechangelog.com/post/3445186374/episode-0-4-9-git-sh... 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.