7 ms·

I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredib

I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git. In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will (did?) happily let you work away at a corrupted repo for weeks until a fresh clone was attempted and the dreaded repo corrupted message killed development for days until the problem was painstakingly manually fixed. This is just personal experience and a lot of it comes down to taste, but IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to. Disclaimer: This was a few years ago now, perhaps the project is more mature than it was.

indygreg2 13y ago
I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1]. Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months. I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible. Some things possible in Mercurial that aren't with Git: * Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands. * Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla. * Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself. * Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation. As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way. [1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/ http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-query-mozilla-metadata/ http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...
- al2o3cr 13y ago
  Maybe it's just me, but recommending a DVCS because it hasn't corrupted your data lately is like recommending a car because it hasn't had the wheels randomly fall off lately.
  - EpicEng 13y ago
    The parent's recommendation was not based upon data not being corrupted lately. He stated that this issue is not as prevalent as it used to be, countering the commentor's slightly outdated experience, and then went on to list off features as the basis of his recommendation.
  - deleted 13y ago
    [deleted]
LukeHoersten 13y ago
I've been using mercurial and git for about 8 years and I've never had corruption problems from either. What are you doing to get corruption errors. Also, mercurial hashes just like git and has for a long time. Are you sure that's not enough to detect corruption issues?
gcb0 13y ago
my first run with git also got me a corrupted repo. never got support for it. but this os pointless, the keyword in your post is "forced".
hawkharris 13y ago
I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)
- rmetzler 13y ago
  Committers are able to sign their commit with their GPG key. Edit: I was wrong and changed all the words
  - Hello71 13y ago
    Not by default it isn't. And git uses GPG, not SSH keys.
    - rmetzler 13y ago
      You're right, I was wrong. I'm sorry.
  - jedbrown 13y ago
    Everything about this comment is wrong. Commits are never signed [EDIT: it is possible since 2011, but rarely used; thanks zobzu]. Annotated tags can be signed via PGP (not SSH keys), but the public key is not stored in the repository (unless you put it there manually, as with the tag "junio-gpg-pub" in git.git, which is not even Junio's current signing key). In practice, people obtain keys from PGP keyservers.
  - zobzu 13y ago
    I can't reply to a child of this comment, but yes, this comment is entirely wrong. However, Git can indeed sign commits (using gpg), not just tags. "git commit -S"
  - blibble 13y ago
    http://mercurial.selenic.com/wiki/GpgExtension http://mercurial.selenic.com/wiki/GpgExtension
pjmlp 13y ago
Funny, at my company it is the oppositive. If you give the developers the choice, they would drop git and go back to mercurial.
- schrodinger 13y ago
  Then why not switch to mercurial?
  - Pacabel 13y ago
    I don't know the specifics of his case, but there could be several reasons. A likely one is that the benefits of a switch wouldn't outweigh the costs, at least not within a reasonable timeframe. Another is that there may not be resources to dedicate to such an effort, even if the return would be suitable. And yet another could be management buying into all of the git hype we've been subjected to a lot lately. Git (and GitHub) today are like Ruby on Rails was a few years back. Even though there are several alternatives, some of them much better in some ways, they just don't get the media attention, and thus don't get hyped, and thus don't get onto the radar of managers who decide which VCS to use, and thus don't see as much use, and thus aren't even seen as viable options by said managers.
    - pjmlp 13y ago
      You got it almost right. We do enterprise consulting and are bound to the technology that is already in place. In 90% of our projects we seldom introduce anything new. Many of our customers have been sold into git hype and have been moving or have recently moved to git.
  - pjmlp 13y ago
    Because as enterprise consultants we use what the customers require, it is not up to us to choose our tooling. Many of those customers have been sold to git hype before getting us on board.
    - codygman 13y ago
falicon 13y ago
Most people prefer what they already know (learning any new system or process is always frustrating because you are attempting to map concept rather than learn concepts - square peg, round hole). I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.
blibble 13y ago
git is as prone to bitrot as hg. git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while. it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).
- jeltz 13y ago
  Mercurial was announced on 2005-04-19 and git on 2005-04-07, so no Mercurial was not first. Edit: Monotone is older than git though.
  - judk 13y ago
    I think we can state they weren't copying each other.
    - jeltz 13y ago
      Indeed, they both were developed separately as a reaction to the BitKeeper drama.
    - tonfa 13y ago
      I think both started on the same day (due to both authors being part of the kernel "kabal" and already in the known about the upcoming bk debacle). Mercurial was usable earlier though ;-) (the first git versions were really really low level, and did not include features like packs, while hg had high kevel command line and its compressed storage format from the first release)
- twic 13y ago
  Moreover, Mercurial's storage scheme is built on append-only files, whereas Git periodically repacks its objects, which means that Mercurial actually has fewer opportunities for cosmic rays to hit the bits while they are in motion, and so less chance of corruption.
  - codex 13y ago
kyrra 13y ago
> but I found it to be incredibly frustrating already knowing git. From my understanding, the terminology and behavior of Mercurial is more in-line with other SCMs out there (like SVN), while Git seems to do things a bit differently. A lot of it is terminology differences or default behavior for various commands. > I found it to be slower, less flexible, Mercurial should be about the same speed as Git now adays. I'd be interested to hear what parts of HG you thought were slow. Also, for flexibility, Mercurial disables a lot of more advanced features by defaults (anything that could get a developer in trouble or mess with history). All of the extensions that ship with Mercurial are officially supported and can be used if you want that functionality. > prone to permanent repository corruption I'd be interested to hear if you ever found out what caused your problems. Mercurial has a page talking about this [0]. > IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to. For almost all features, I'd totally agree. There are 3 things in Mercurial that I see as an advantage over Git. (1) named branches (every commit on the branch will be tagged with the branch name). (2) LargeFile[1] extension for handling very large files you don't want people having to pull, though this breaks DVCS concepts. (3) A future feature that looks really promising, ChangesetEvolution[2], that will basically allow history rewriting that can be pushed to others. [0] http://mercurial.selenic.com/wiki/RepositoryCorruption http://mercurial.selenic.com/wiki/RepositoryCorruption [1] http://mercurial.selenic.com/wiki/LargefilesExtension http://mercurial.selenic.com/wiki/LargefilesExtension [2] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
tootie 13y ago
I personally find git staging to be a major inconvenience and would rather not have it around.

indygreg2 13y ago

I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1]. Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months. I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible. Some things possible in Mercurial that aren't with Git: * Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands. * Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla. * Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself. * Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation. As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way. [1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/ http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-query-mozilla-metadata/ http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...

al2o3cr 13y ago
Maybe it's just me, but recommending a DVCS because it hasn't corrupted your data lately is like recommending a car because it hasn't had the wheels randomly fall off lately.
- EpicEng 13y ago
  The parent's recommendation was not based upon data not being corrupted lately. He stated that this issue is not as prevalent as it used to be, countering the commentor's slightly outdated experience, and then went on to list off features as the basis of his recommendation.
- deleted 13y ago
  [deleted]

LukeHoersten 13y ago

I've been using mercurial and git for about 8 years and I've never had corruption problems from either. What are you doing to get corruption errors. Also, mercurial hashes just like git and has for a long time. Are you sure that's not enough to detect corruption issues?

gcb0 13y ago

my first run with git also got me a corrupted repo. never got support for it. but this os pointless, the keyword in your post is "forced".

hawkharris 13y ago

I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)

rmetzler 13y ago
Committers are able to sign their commit with their GPG key. Edit: I was wrong and changed all the words
- Hello71 13y ago
  Not by default it isn't. And git uses GPG, not SSH keys.
  - rmetzler 13y ago
    You're right, I was wrong. I'm sorry.
- jedbrown 13y ago
  Everything about this comment is wrong. Commits are never signed [EDIT: it is possible since 2011, but rarely used; thanks zobzu]. Annotated tags can be signed via PGP (not SSH keys), but the public key is not stored in the repository (unless you put it there manually, as with the tag "junio-gpg-pub" in git.git, which is not even Junio's current signing key). In practice, people obtain keys from PGP keyservers.
- zobzu 13y ago
  I can't reply to a child of this comment, but yes, this comment is entirely wrong. However, Git can indeed sign commits (using gpg), not just tags. "git commit -S"
- blibble 13y ago
  http://mercurial.selenic.com/wiki/GpgExtension http://mercurial.selenic.com/wiki/GpgExtension

pjmlp 13y ago

Funny, at my company it is the oppositive. If you give the developers the choice, they would drop git and go back to mercurial.

schrodinger 13y ago
Then why not switch to mercurial?
- Pacabel 13y ago
  I don't know the specifics of his case, but there could be several reasons. A likely one is that the benefits of a switch wouldn't outweigh the costs, at least not within a reasonable timeframe. Another is that there may not be resources to dedicate to such an effort, even if the return would be suitable. And yet another could be management buying into all of the git hype we've been subjected to a lot lately. Git (and GitHub) today are like Ruby on Rails was a few years back. Even though there are several alternatives, some of them much better in some ways, they just don't get the media attention, and thus don't get hyped, and thus don't get onto the radar of managers who decide which VCS to use, and thus don't see as much use, and thus aren't even seen as viable options by said managers.
  - pjmlp 13y ago
    You got it almost right. We do enterprise consulting and are bound to the technology that is already in place. In 90% of our projects we seldom introduce anything new. Many of our customers have been sold into git hype and have been moving or have recently moved to git.
- pjmlp 13y ago
  Because as enterprise consultants we use what the customers require, it is not up to us to choose our tooling. Many of those customers have been sold to git hype before getting us on board.
  - codygman 13y ago

falicon 13y ago

Most people prefer what they already know (learning any new system or process is always frustrating because you are attempting to map concept rather than learn concepts - square peg, round hole). I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.

blibble 13y ago

git is as prone to bitrot as hg. git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while. it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).

jeltz 13y ago
Mercurial was announced on 2005-04-19 and git on 2005-04-07, so no Mercurial was not first. Edit: Monotone is older than git though.
- judk 13y ago
  I think we can state they weren't copying each other.
  - jeltz 13y ago
    Indeed, they both were developed separately as a reaction to the BitKeeper drama.
  - tonfa 13y ago
    I think both started on the same day (due to both authors being part of the kernel "kabal" and already in the known about the upcoming bk debacle). Mercurial was usable earlier though ;-) (the first git versions were really really low level, and did not include features like packs, while hg had high kevel command line and its compressed storage format from the first release)
twic 13y ago
Moreover, Mercurial's storage scheme is built on append-only files, whereas Git periodically repacks its objects, which means that Mercurial actually has fewer opportunities for cosmic rays to hit the bits while they are in motion, and so less chance of corruption.
- codex 13y ago

kyrra 13y ago

> but I found it to be incredibly frustrating already knowing git. From my understanding, the terminology and behavior of Mercurial is more in-line with other SCMs out there (like SVN), while Git seems to do things a bit differently. A lot of it is terminology differences or default behavior for various commands. > I found it to be slower, less flexible, Mercurial should be about the same speed as Git now adays. I'd be interested to hear what parts of HG you thought were slow. Also, for flexibility, Mercurial disables a lot of more advanced features by defaults (anything that could get a developer in trouble or mess with history). All of the extensions that ship with Mercurial are officially supported and can be used if you want that functionality. > prone to permanent repository corruption I'd be interested to hear if you ever found out what caused your problems. Mercurial has a page talking about this [0]. > IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to. For almost all features, I'd totally agree. There are 3 things in Mercurial that I see as an advantage over Git. (1) named branches (every commit on the branch will be tagged with the branch name). (2) LargeFile[1] extension for handling very large files you don't want people having to pull, though this breaks DVCS concepts. (3) A future feature that looks really promising, ChangesetEvolution[2], that will basically allow history rewriting that can be pushed to others. [0] http://mercurial.selenic.com/wiki/RepositoryCorruption http://mercurial.selenic.com/wiki/RepositoryCorruption [1] http://mercurial.selenic.com/wiki/LargefilesExtension http://mercurial.selenic.com/wiki/LargefilesExtension [2] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution

tootie 13y ago

I personally find git staging to be a major inconvenience and would rather not have it around.