6 ms·

Why I Switched to Git From Mercurial

176 points by pilif 16y ago

pilif 16y ago
personally, I really don't get the complaints about git's UI. OK. I understand the confusion about what checkout does, though on the other hand, once you know that, it won't happen to you. But a revision control system failing to not corrupt or crash depending on the data you put into it is, frankly, no revision control system. Just like a database failing to return the same data back that you told it to store and without telling you a problem occurred at store time is no database either (cough mysql cough).
- davidw 16y ago
  > I really don't get the complaints about git's UI I would group mine into two main categories: * Error messages that are confusing. * Requiring that the user knows a fair number of options to commands. You can get by in svn without knowing many options to pass to commands, but with git, you're going to sink if you don't.
  - Xurinos 16y ago
    Error messages that are confusing. Which ones? I have found them helpful, suggesting the right possible commands to use to solve a problem. Requiring that the user knows a fair number of options to commands. Which ones? "git add", "git commit", "git push", "git log", "git revert", "git checkout", "git merge", and "git branch" do not require any options unless you want some shortcuts or useful things that SVN cannot do.
    - jerf 16y ago
      The error messages have been undergoing fairly rapid change lately, as in, over the past year. I'd say that anyone complaining about the error messages should double-check that they have a very recent version. If you're just using your distro's version you may be a ways back. That said, there are still some error messages that are quite good, if you understand git's model, but if you don't are nearly opaque. (Easy to google, though.) Git really is unfriendly to you if you're just trying to hack along without understanding how it works, and I don't see that ever changing. It's a power tool, not a butter knife, and while it can, should, and does have guards in the right place to keep you from really hurting yourself (you basically can't lose data in the repository, thanks to reflog; be careful with checkout, though), it's not ever going to be quite as simple as a casual user would like. If it was, it wouldn't be git anymore.
    - ubercore 16y ago
      An example that trips me up frequently is creating a remote branch, then tracking it in a local branch. This is by far my most common workflow, but as far as I've learned so far, involves a couple of commands with some easy to forget options. Granted, after a few times I just wrote it down, and now mostly remember, but it's not as simple as it potentially could be. I was also a little shocked to find that I couldn't simply start tracking a remote branch after a local branch had already been created -- requires git 1.7. The workaround was simple (create a new tracking branch and merge the changes over), but to me this is an example of the UI being a little unhelpful.
- danh 16y ago
  "I really don't get the complaints about git's UI" I think it's because git's data model is so minimal and elegant, and the UI is anything but. For me, it's not so much that the UI is quite bad (which it is), but that it could have been brilliant.
  - etherealG 16y ago
    Perhaps you could elaborate on a UI design that would be brilliant. Even better, code it, if you can improve do. I'll tell you what, if you even succeed in describing such an interface, I'll build it for you.
    - defrex 16y ago
      See bazaar.canonical.com.
      - etherealG 16y ago
        a cursory glance at the screenshots there show it similar to git gui / gitx or similar. I'm talking about fundamental interaction with the version control system, not a pretty gui. git has pretty gui too.
        mbrubeck 16y ago
        It's not just the GUI - bzr has one of the better-designed command line UIs too. It's very similar to Mercurial's, plus some nice things borrowed from other systems but integrated very consistently. (But I do agree that there's more to a VCS than UI design, and after the initial learning curve there's not a huge difference in command-line usage between the popular systems.)
        __david__ 16y ago
        I disagree. I found bzr to be a mishmash of poorly thought out options and features. A quick example: Compare bzr log's "-r" option to "git rev-list". bzr's "A..B" is stupidly inclusive on both ends making scripting very difficult. If you want a really nice, consistent UI, check out darcs.
- sandGorgon 16y ago
  Why is git still a collection of bash scripts ? Does nobody care enough to wrap the core into a library (yes, i do know about the glacial libgit2 project) and put a Python/Ruby/Lua interface over it ? Dulwich exists, but it is not a drop-in replacement. When will I get a true platform independent Git (none of the msysgit stuff) ?
  - fr0sty 16y ago
    It is still bash because bash is more universal than Python+Ruby+Lua. The only place bash doesn't exist is on Windows and installing Cygwin is the least of your worries in that case.
    - sandGorgon 16y ago
      we have selenium testcases that need to be run on IE. We need to have a revision control on windows. Please dont be dismissive of windows just because you can, some of us have to make a living.
- wisty 16y ago
  I don't think there is a problem with the UI. I don't use git, but by the tone of the comments people seem to be unable to use it, and therefore blame the UI. I think the real problem is the documentation, both official and unofficial. The best git intro I could find was gittutorial. It's OK, but a bit unfriendly. Everything else rapidly goes from telling you how to do stuff to teaching you how git works. If somebody came from SVN and told me that hg was unintuitive I'd tell them it's pretty easy, and they just have to get used to a slightly different model. Then I'd tell they to try hginit.com. I'd also point out how they can still work while the network is hosed, and that even if the server dies they still have all the history. Cool, isn't it? git users tell people to learn graph theory.
- skybrian 16y ago
  Coming from Perforce, I'd say that git's model seems overly rigid. In Perforce, workflow looks like this: - edit files A, B, C, D, E in the default changelist. - put A and B in changelist #1 - put C, D, E in changelist #2 - oops, C is the wrong changelist. Move it to #1. - edit file F (starts out in default changelist) - put F in changelist #1 - send both changelists out for review. - edit file B based on review. Run tests to make sure both CLs work together. - commit one of the CL's So the basic idea is that I have multiple changelists open simultaneously and the contents of the changelists are fluid. I can keep changing my mind about them until commit. Of course, since Perforce CL's are file-based, this all breaks down if I want overlapping uncommitted CL's. Git handles that better, which is why I'm using Git now. But I still miss the ease of use of Perforce when working on multiple CL's. Sure, the commits in Git are only local and you can always edit them until you do a push, but it seems like I have to plan ahead more and commit more often, or I end up having to split or merge CL's using commands I'm not very comfortable with.
  - koenigdavidmj 16y ago
    Not sure if you know about Perforce's shelving feature, but it might be useful for you. Here's how it looks: 1. Hack on files 'foo' and 'bar', but instead of saying `p4 change`, say `p4 shelve`. Write down the changelist number for later; this changelist is stored on the server now. 2. `p4 revert foo bar`. You don't lose any changes; they're all on the server. 3. Hack on files 'bar' and 'baz'. Submit or shelve those changes. 4. `p4 unshelve -c (changelist number from step 1)`. (You'll probably need to resolve here.) Your original changes are back! Git certainly breaks down if you're working on one massive branch, but it's designed for lots of branching. Go ahead; we're encouraging you to branch for every new feature, every bug fix, everything. Here's the above workflow in git: 1. `git checkout -b first-change`. Hack on files 'foo' and 'bar' and commit. 2. `git checkout old-branch`, where 'old-branch' is the branch that you were on before step 1, probably 'master'. Now `git checkout -b second-change` and edit files 'bar' and 'baz'. Commit again. 3. Checkout the old branch (master, likely) again. `git merge first-change`. `git merge second-change`. Resolve if required. Test. Push changes to the remote server. Best of all, you don't need to branch before making your changes. You could actually move the `git checkout -b first-change` to after the edits on that branch, and it would still do what you want.
ErrantX 16y ago
I use Mercurial and much much prefer it to Git (personal preference, I'll try not to evangalize) In part he is dead on. hg really can't handle large repositories; but to be honest if you're working with GB's of data then you're using the wrong tool :) period. Point two is a "complaint" I agree with. The repository structure isn't particularly good - it "works" for the most part but sometimes you just want to kick it. And forget hacking around with it.. Silly things like "hg copy [file]" doesn't copy file history but does a remove/add & cp/rm are another ball ache. Ultimately hg is a good tool; for lightweight, hackerish version control it is great. Beyond that? Yeh, use Git.
- lenni 16y ago
  I agree mostly. A large port tree shouldn't be checked into a source code management system,
  - compay 16y ago
    For sure. But I do think it's just a sign of good design that Git is easily usable in ways that are unexpected and outside its original intended purpose.
- tjogin 16y ago
  But isn't also Git just as good at the stuff you think hg is good at?
  - ErrantX 16y ago
    Yes.... though it is more complex (and in my experience a lot of that complexity is not needed by most). So hg is a nice portable alternative.
    - charlesmarshall 16y ago
      What part do you find complicated about git? The basic commands are: git clone, git add, git commit, git push ... most of these are handled by guis (tortoise, gitx, etc) so all you have to do then is click the right button
sreque 16y ago
The author states three reasons for switching. 1. Problems with storing big files in Mercurial. You can use the bigfiles extension if you really want to manage large files with Mercurial. 2. Inefficient renames. Making renames efficient is a currently recommended GSoC project. I'm sure this will be fixed eventually even if no one picks it up this summer. 3. Destructive commands actually, well, destroying stuff. This point makes me feel like the author knew git first, tried mercurial out, and switched back, making the blog post a little misleading. I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. If I were to run a delete command in Mercurial, I would read the documentation on the command first to make sure it created a backup for me. Only if it then failed to create this backup would I complain. Also, I think I prefer the bundle approach of Mercurial. You can always rename the bundles to keep track of them. You could even write your own extension in 5 lines that ran a destructive command and immediately unbundled the created bundle to restore your changesets, exactly duplicating git's functionality. The first two issues he mentions I would consider to be actually valid complaints against Mercurial, the third just a personal preference of the author. I would consider neither of them to be major game-changing issues.
- pilif 16y ago
  I don't know about Mercurial, but in your IDE / Editor, don't you like having multi-step undo no matter what command you execute? Or do you prefer to manually backup the files of your project before doing any operation in your editor that is potentially destroying your files? I'd much rather hit ctrl-z as many times as needed once I noticed my last refactoring has shredded all the files it touched. Being able to easily undo whatever I do to in whatever application I can think of is a nice feature - even more so if the application is what I entrust all my work to.
  - sreque 16y ago
    When I run sed on a file, I don't expect it to make a backup copy of my file. Similarly, when I run rm, it doesn't create a backup of what I'm deleting. Destructive operations are, well, destructive! I'm amazed at the response I got to my post. Read the docs on a mercurial command. Chances are if it is destructive it creates a backup for you. On the off chance that someone writes an extension that fails to do so, you can create the backup yourself. There's nothing magic about git's operation here. Someone simply took the time to create a backup in git for a command for which the equivalent mercurial command didn't. Big deal.
jozeph78 16y ago
Thanks for this good article. I took a 15 minute tour of both HG and Git and felt that hg was overall a better experience, but felt if the community is moving towards Git there has to be some good reason. I'm always a fan of the underdog, so I've been asking everyone why Git (besides Github of course). This is the first article that gives real pitfalls of one vs the other. I enjoyed the read and would love to hear more as well as counter arguments.
- tghw 16y ago
  What makes you think Git is the underdog?
  - orlandu63 16y ago
    I think he's implying that Mercurial is the underdog
    - nocman 16y ago
      Yeah, that's the way I read it also.
- pohl 16y ago
  ... but felt if the community is moving towards Git there has to be some good reason... Must there? What if most people are switching based on the same vague feeling that there must be some reason behind the shape of the swarm? (I'm a fan of both systems here, fwiw.)
- gte910h 16y ago
  Hg is going to usually be something you pick up slightly faster. It is between much and very on the intuitive scale. On the same note, once you get to competency (between 2 weeks and 4 months of use, depending on the person), git is more easy to manipulate and do the sort of things you often have to do when working with people on a project. While somewhat unintuitive in some of the commands or the default arguments you may need, git is perfectly decipherable and memorable once you do get through the initial period. Additionally, as git is often handled on the command line (even by people who'd usually use GUI programs), it LOOKS more intimidating, but it seems a few weeks in, people are getting by with Hg (As they don't have to get what's going on) however can do pretty complicated stuff in git (as you have to get what's happening or you will be lost).
durin42 16y ago
With respect to his claim hg lost data for him, he was using mq without really understanding it or using a versioned queue. mq is disabled for a reason, and he enabled it without fully understanding the risks and ways of mitigating those risks. I've discussed this with him at times, but the message never seems to connect.
- garybernhardt 16y ago
  Augie, I understand what you're saying, and I don't buy it. Git, when taken as a full DVCS capable of rewriting history, is safer than Mercurial, when taken as a full DVCS capable of rewriting history. A DVCS that is incapable of rewriting history is, for me, a nonstarter, so I'm not interested in talking about "well, if you turn off the interesting parts of Mercurial, it's perfectly safe!" You can either use Mercurial in a mode where it's not at all equivalent to Git, but safe (extensions off), or you can use it in a mode where it's somewhat equivalent to Git, but might lose your data. With Git, I can mutate history without the slightest bit of fear, often just to see what will happen. Does this giant branch I discarded two months ago rebase cleanly over master? Try it. If the rebase completes but I don't like it, I "git reset mybranch@{1}" and everything is good. And that safety net is always there. In Mercurial, I have to stop and think every time. Even if the command does dump a bundle, restoring from it is a special case, and I'm going to have to go dig up the bundle file, and in some cases it might not be there and I'll be screwed. In Git, there are no special cases, I always know exactly how to recover, and the recovery mechanism is always there. Once more, to be clear: In Git, it is always there. Always there!
  - utx00 16y ago
    i guess i will have to try git to be sure, but i really don't see a difference here. usually if i'm going to try something drastic, i try it on a clone that i know i can throw away.
    - garybernhardt 16y ago
      I often do it multiple times per minute. That wouldn't fly if each required a clone. :) (See another post I made in this thread for what I'm doing that involves so much history mutation.)
pacemkr 16y ago
"It's just an interface, though, and this is a tool you are going to use every day..." This summarized, for me, why I use hg. It is a tool I am going to use everyday and it's not ok for this tool to have a crappy interface. My hard drive space, that I don't care about.
- garybernhardt 16y ago
  Did you read the end? ;) """ I'm sorry for recommending software with a confusing interface. But you'll be spending a lot of time with it; it's worth getting over the initial hurdle of confusion. """ Note that I call it the "initial hurdle". I know both systems very well, and Mercurial gets in my way far, far more than Git.
- charlesmarshall 16y ago
  not all guis are made equal, depends which is being used to how good or bad it is. I use gitx on osx (http://gitx.frim.nl/ http://gitx.frim.nl/), other than the lack of a 'push' button its spot on, simple to use and powerful.
- j_baker 16y ago
  git's interface isn't terribly intuitive, but it isn't that bad. Once you get the hang of it, it makes sense.
  - anthonyb 16y ago
    I really don't follow this argument. git's interface is a giant turd. I've been using it for months, and it still hasn't stuck, no matter what tutorials I read. The normal workflow needs far too many commands and special options, local vs. remote branching seems to do weird things, and the error messages are completely obtuse.
- njharman 16y ago
  Yeah, I too thought the logic of that statement was completely back asswords.
mbrubeck 16y ago
I've used Git for three years, at two different companies and various personal and community projects. I sync my home directory between hosts using git, I have administered multi-user git repos using gitosis, and I have been a GitHub user since early 2008. I started using Mercurial two months ago when I joined the Mozilla corporation, and now use it every day on one of the biggest and best-supported installations in the world. I also started using BitBucket for some of my Mozilla-related personal projects. It might be that I don't fully "get" Mercurial yet, but I still find myself frequently missing Git. My first impression is that Git has a simple flexible model that supports a complex front-end, while Mercurial has a simple extensible front-end that ends up creating a somewhat more complicated model. Any time I need to step outside the standard commit-merge-push workflow, I find the higher level of abstraction between Mercurial's user commands and its database makes it harder to understand what I'm doing, and sometimes prevents me from doing what I want. Things like rewriting history (e.g. for rebasing), or combining changes from multiple remote repos with different sets of branches, are still possible in Mercurial - but they usually require plugins to do well, there are more different incompatible ways to do them, and there are more opportunities to mess up your repo. More concretely, I find that MQ is the best way to do many tasks in Mercurial that I would do in git with plain old branches and commits, and for many of these uses MQ is both more complicated and less flexible than the equivalent git commands. (But there are other uses where MQ is really better than the alternatives.) I also find that it's much more annoying to manage short-lived throwaway or topic branches in Mercurial, so much that I simply avoid using them much of the time. But perhaps I'm just brainwashed (or brain-damaged) from too many years with Git. :)
- sreque 16y ago
  For creating temporary local branches, have you tried the bookmarks and localbranch extensions? Also, I am be interested to learn more about your workflow and why it is so difficult to do in Mercurial. So far, the only feature I've seen in git that I've wanted in Mercurial is the ability to manage publicly named branches using the bookmarks extension, and by extension, an easy way to track named branches.
- jwr 16y ago
  Good point about MQ, before people pointed me to it, I was continuously surprised by many things I could not easily do in hg. The DVCS crowd looks down on centralized VCSses and points out that whenever the answer to a VCS question begins with "well, you should have done X before you did this…", it marks a failure. Fair enough. But I would extend that further — when I ask "how do I do X with this VCS", I don't want to be told "well see, you don't really want to be doing X". Yes I do want to, and I want a VCS that let's me do pretty much anything I want. That's git's approach.
psranga 16y ago
I thought Git handled huge files poorly too. What I'd read was that most algos in git assume that the whole file in revision control can be held in memory at once to do things like diff. Has this changed, or was I always mistaken, or this guy talking about the sum of file sizes being a few gig?
- sandGorgon 16y ago
  I cant find the resource, but sometime back someone compared DVCS for large binary files (game assets) and saw they were absolutely inefficient .. and in several case incapable of handling large files
- avar 16y ago
  It still handles them poorly by default. You can do things like edit .gitattributes to say that e.g. a *.binary file should be treated specially, but Git's still not a good system for e.g. archiving HD video. Some of this can be fixed, but a lot of it is probably not going to change. When you git-add something it has to checksum the old data + new data. That's going to be a pretty expensive operation when you have 50TB of data. There's no DVCS that I'm aware of that handles large binary files as well as say Perforce or Subversion. Check out this project for more info on tuning Git for big files: http://caca.zoy.org/wiki/git-bigfiles http://caca.zoy.org/wiki/git-bigfiles
avar 16y ago
This is always relevant: http://keithp.com/blogs/Repository_Formats_Matter/ http://keithp.com/blogs/Repository_Formats_Matter/ "I would like to argue that none of the user-interface and high-level functional details are nearly as important as the fundamental repository structure. When evaluating source code management systems, I primarily researched the repository structures and essentially ignored the user interface details. We can fix the user interface over time and even add features. We cannot, however, fix a broken repository structure without all of the pain inherent in changing systems." Keith makes a good point. While Git's interface is lacking in some areas, those things can be fixed in the higher level porcelain. Picking a system with a nicer interface whose plumbing is uglier will lead to problems further down the road.

176 points by pilif 16y ago

pilif 16y ago

personally, I really don't get the complaints about git's UI. OK. I understand the confusion about what checkout does, though on the other hand, once you know that, it won't happen to you. But a revision control system failing to not corrupt or crash depending on the data you put into it is, frankly, no revision control system. Just like a database failing to return the same data back that you told it to store and without telling you a problem occurred at store time is no database either (cough mysql cough).

davidw 16y ago
> I really don't get the complaints about git's UI I would group mine into two main categories: * Error messages that are confusing. * Requiring that the user knows a fair number of options to commands. You can get by in svn without knowing many options to pass to commands, but with git, you're going to sink if you don't.
- Xurinos 16y ago
  Error messages that are confusing. Which ones? I have found them helpful, suggesting the right possible commands to use to solve a problem. Requiring that the user knows a fair number of options to commands. Which ones? "git add", "git commit", "git push", "git log", "git revert", "git checkout", "git merge", and "git branch" do not require any options unless you want some shortcuts or useful things that SVN cannot do.
  - jerf 16y ago
    The error messages have been undergoing fairly rapid change lately, as in, over the past year. I'd say that anyone complaining about the error messages should double-check that they have a very recent version. If you're just using your distro's version you may be a ways back. That said, there are still some error messages that are quite good, if you understand git's model, but if you don't are nearly opaque. (Easy to google, though.) Git really is unfriendly to you if you're just trying to hack along without understanding how it works, and I don't see that ever changing. It's a power tool, not a butter knife, and while it can, should, and does have guards in the right place to keep you from really hurting yourself (you basically can't lose data in the repository, thanks to reflog; be careful with checkout, though), it's not ever going to be quite as simple as a casual user would like. If it was, it wouldn't be git anymore.
  - ubercore 16y ago
    An example that trips me up frequently is creating a remote branch, then tracking it in a local branch. This is by far my most common workflow, but as far as I've learned so far, involves a couple of commands with some easy to forget options. Granted, after a few times I just wrote it down, and now mostly remember, but it's not as simple as it potentially could be. I was also a little shocked to find that I couldn't simply start tracking a remote branch after a local branch had already been created -- requires git 1.7. The workaround was simple (create a new tracking branch and merge the changes over), but to me this is an example of the UI being a little unhelpful.
danh 16y ago
"I really don't get the complaints about git's UI" I think it's because git's data model is so minimal and elegant, and the UI is anything but. For me, it's not so much that the UI is quite bad (which it is), but that it could have been brilliant.
- etherealG 16y ago
  Perhaps you could elaborate on a UI design that would be brilliant. Even better, code it, if you can improve do. I'll tell you what, if you even succeed in describing such an interface, I'll build it for you.
  - defrex 16y ago
    See bazaar.canonical.com.
    - etherealG 16y ago
      a cursory glance at the screenshots there show it similar to git gui / gitx or similar. I'm talking about fundamental interaction with the version control system, not a pretty gui. git has pretty gui too.
      - mbrubeck 16y ago
        It's not just the GUI - bzr has one of the better-designed command line UIs too. It's very similar to Mercurial's, plus some nice things borrowed from other systems but integrated very consistently. (But I do agree that there's more to a VCS than UI design, and after the initial learning curve there's not a huge difference in command-line usage between the popular systems.)
        __david__ 16y ago
        I disagree. I found bzr to be a mishmash of poorly thought out options and features. A quick example: Compare bzr log's "-r" option to "git rev-list". bzr's "A..B" is stupidly inclusive on both ends making scripting very difficult. If you want a really nice, consistent UI, check out darcs.
sandGorgon 16y ago
Why is git still a collection of bash scripts ? Does nobody care enough to wrap the core into a library (yes, i do know about the glacial libgit2 project) and put a Python/Ruby/Lua interface over it ? Dulwich exists, but it is not a drop-in replacement. When will I get a true platform independent Git (none of the msysgit stuff) ?
- fr0sty 16y ago
  It is still bash because bash is more universal than Python+Ruby+Lua. The only place bash doesn't exist is on Windows and installing Cygwin is the least of your worries in that case.
  - sandGorgon 16y ago
    we have selenium testcases that need to be run on IE. We need to have a revision control on windows. Please dont be dismissive of windows just because you can, some of us have to make a living.
wisty 16y ago
I don't think there is a problem with the UI. I don't use git, but by the tone of the comments people seem to be unable to use it, and therefore blame the UI. I think the real problem is the documentation, both official and unofficial. The best git intro I could find was gittutorial. It's OK, but a bit unfriendly. Everything else rapidly goes from telling you how to do stuff to teaching you how git works. If somebody came from SVN and told me that hg was unintuitive I'd tell them it's pretty easy, and they just have to get used to a slightly different model. Then I'd tell they to try hginit.com. I'd also point out how they can still work while the network is hosed, and that even if the server dies they still have all the history. Cool, isn't it? git users tell people to learn graph theory.
skybrian 16y ago
Coming from Perforce, I'd say that git's model seems overly rigid. In Perforce, workflow looks like this: - edit files A, B, C, D, E in the default changelist. - put A and B in changelist #1 - put C, D, E in changelist #2 - oops, C is the wrong changelist. Move it to #1. - edit file F (starts out in default changelist) - put F in changelist #1 - send both changelists out for review. - edit file B based on review. Run tests to make sure both CLs work together. - commit one of the CL's So the basic idea is that I have multiple changelists open simultaneously and the contents of the changelists are fluid. I can keep changing my mind about them until commit. Of course, since Perforce CL's are file-based, this all breaks down if I want overlapping uncommitted CL's. Git handles that better, which is why I'm using Git now. But I still miss the ease of use of Perforce when working on multiple CL's. Sure, the commits in Git are only local and you can always edit them until you do a push, but it seems like I have to plan ahead more and commit more often, or I end up having to split or merge CL's using commands I'm not very comfortable with.
- koenigdavidmj 16y ago
  Not sure if you know about Perforce's shelving feature, but it might be useful for you. Here's how it looks: 1. Hack on files 'foo' and 'bar', but instead of saying `p4 change`, say `p4 shelve`. Write down the changelist number for later; this changelist is stored on the server now. 2. `p4 revert foo bar`. You don't lose any changes; they're all on the server. 3. Hack on files 'bar' and 'baz'. Submit or shelve those changes. 4. `p4 unshelve -c (changelist number from step 1)`. (You'll probably need to resolve here.) Your original changes are back! Git certainly breaks down if you're working on one massive branch, but it's designed for lots of branching. Go ahead; we're encouraging you to branch for every new feature, every bug fix, everything. Here's the above workflow in git: 1. `git checkout -b first-change`. Hack on files 'foo' and 'bar' and commit. 2. `git checkout old-branch`, where 'old-branch' is the branch that you were on before step 1, probably 'master'. Now `git checkout -b second-change` and edit files 'bar' and 'baz'. Commit again. 3. Checkout the old branch (master, likely) again. `git merge first-change`. `git merge second-change`. Resolve if required. Test. Push changes to the remote server. Best of all, you don't need to branch before making your changes. You could actually move the `git checkout -b first-change` to after the edits on that branch, and it would still do what you want.

ErrantX 16y ago

I use Mercurial and much much prefer it to Git (personal preference, I'll try not to evangalize) In part he is dead on. hg really can't handle large repositories; but to be honest if you're working with GB's of data then you're using the wrong tool :) period. Point two is a "complaint" I agree with. The repository structure isn't particularly good - it "works" for the most part but sometimes you just want to kick it. And forget hacking around with it.. Silly things like "hg copy [file]" doesn't copy file history but does a remove/add & cp/rm are another ball ache. Ultimately hg is a good tool; for lightweight, hackerish version control it is great. Beyond that? Yeh, use Git.

lenni 16y ago
I agree mostly. A large port tree shouldn't be checked into a source code management system,
- compay 16y ago
  For sure. But I do think it's just a sign of good design that Git is easily usable in ways that are unexpected and outside its original intended purpose.
tjogin 16y ago
But isn't also Git just as good at the stuff you think hg is good at?
- ErrantX 16y ago
  Yes.... though it is more complex (and in my experience a lot of that complexity is not needed by most). So hg is a nice portable alternative.
  - charlesmarshall 16y ago
    What part do you find complicated about git? The basic commands are: git clone, git add, git commit, git push ... most of these are handled by guis (tortoise, gitx, etc) so all you have to do then is click the right button

sreque 16y ago

The author states three reasons for switching. 1. Problems with storing big files in Mercurial. You can use the bigfiles extension if you really want to manage large files with Mercurial. 2. Inefficient renames. Making renames efficient is a currently recommended GSoC project. I'm sure this will be fixed eventually even if no one picks it up this summer. 3. Destructive commands actually, well, destroying stuff. This point makes me feel like the author knew git first, tried mercurial out, and switched back, making the blog post a little misleading. I don't know how you could expect a delete not to be a delete unless you were familiar with something like git already. If I were to run a delete command in Mercurial, I would read the documentation on the command first to make sure it created a backup for me. Only if it then failed to create this backup would I complain. Also, I think I prefer the bundle approach of Mercurial. You can always rename the bundles to keep track of them. You could even write your own extension in 5 lines that ran a destructive command and immediately unbundled the created bundle to restore your changesets, exactly duplicating git's functionality. The first two issues he mentions I would consider to be actually valid complaints against Mercurial, the third just a personal preference of the author. I would consider neither of them to be major game-changing issues.

pilif 16y ago
I don't know about Mercurial, but in your IDE / Editor, don't you like having multi-step undo no matter what command you execute? Or do you prefer to manually backup the files of your project before doing any operation in your editor that is potentially destroying your files? I'd much rather hit ctrl-z as many times as needed once I noticed my last refactoring has shredded all the files it touched. Being able to easily undo whatever I do to in whatever application I can think of is a nice feature - even more so if the application is what I entrust all my work to.
- sreque 16y ago
  When I run sed on a file, I don't expect it to make a backup copy of my file. Similarly, when I run rm, it doesn't create a backup of what I'm deleting. Destructive operations are, well, destructive! I'm amazed at the response I got to my post. Read the docs on a mercurial command. Chances are if it is destructive it creates a backup for you. On the off chance that someone writes an extension that fails to do so, you can create the backup yourself. There's nothing magic about git's operation here. Someone simply took the time to create a backup in git for a command for which the equivalent mercurial command didn't. Big deal.

jozeph78 16y ago

Thanks for this good article. I took a 15 minute tour of both HG and Git and felt that hg was overall a better experience, but felt if the community is moving towards Git there has to be some good reason. I'm always a fan of the underdog, so I've been asking everyone why Git (besides Github of course). This is the first article that gives real pitfalls of one vs the other. I enjoyed the read and would love to hear more as well as counter arguments.

tghw 16y ago
What makes you think Git is the underdog?
- orlandu63 16y ago
  I think he's implying that Mercurial is the underdog
  - nocman 16y ago
    Yeah, that's the way I read it also.
pohl 16y ago
... but felt if the community is moving towards Git there has to be some good reason... Must there? What if most people are switching based on the same vague feeling that there must be some reason behind the shape of the swarm? (I'm a fan of both systems here, fwiw.)
gte910h 16y ago
Hg is going to usually be something you pick up slightly faster. It is between much and very on the intuitive scale. On the same note, once you get to competency (between 2 weeks and 4 months of use, depending on the person), git is more easy to manipulate and do the sort of things you often have to do when working with people on a project. While somewhat unintuitive in some of the commands or the default arguments you may need, git is perfectly decipherable and memorable once you do get through the initial period. Additionally, as git is often handled on the command line (even by people who'd usually use GUI programs), it LOOKS more intimidating, but it seems a few weeks in, people are getting by with Hg (As they don't have to get what's going on) however can do pretty complicated stuff in git (as you have to get what's happening or you will be lost).

durin42 16y ago

With respect to his claim hg lost data for him, he was using mq without really understanding it or using a versioned queue. mq is disabled for a reason, and he enabled it without fully understanding the risks and ways of mitigating those risks. I've discussed this with him at times, but the message never seems to connect.

garybernhardt 16y ago
Augie, I understand what you're saying, and I don't buy it. Git, when taken as a full DVCS capable of rewriting history, is safer than Mercurial, when taken as a full DVCS capable of rewriting history. A DVCS that is incapable of rewriting history is, for me, a nonstarter, so I'm not interested in talking about "well, if you turn off the interesting parts of Mercurial, it's perfectly safe!" You can either use Mercurial in a mode where it's not at all equivalent to Git, but safe (extensions off), or you can use it in a mode where it's somewhat equivalent to Git, but might lose your data. With Git, I can mutate history without the slightest bit of fear, often just to see what will happen. Does this giant branch I discarded two months ago rebase cleanly over master? Try it. If the rebase completes but I don't like it, I "git reset mybranch@{1}" and everything is good. And that safety net is always there. In Mercurial, I have to stop and think every time. Even if the command does dump a bundle, restoring from it is a special case, and I'm going to have to go dig up the bundle file, and in some cases it might not be there and I'll be screwed. In Git, there are no special cases, I always know exactly how to recover, and the recovery mechanism is always there. Once more, to be clear: In Git, it is always there. Always there!
- utx00 16y ago
  i guess i will have to try git to be sure, but i really don't see a difference here. usually if i'm going to try something drastic, i try it on a clone that i know i can throw away.
  - garybernhardt 16y ago
    I often do it multiple times per minute. That wouldn't fly if each required a clone. :) (See another post I made in this thread for what I'm doing that involves so much history mutation.)

pacemkr 16y ago

"It's just an interface, though, and this is a tool you are going to use every day..." This summarized, for me, why I use hg. It is a tool I am going to use everyday and it's not ok for this tool to have a crappy interface. My hard drive space, that I don't care about.

garybernhardt 16y ago
Did you read the end? ;) """ I'm sorry for recommending software with a confusing interface. But you'll be spending a lot of time with it; it's worth getting over the initial hurdle of confusion. """ Note that I call it the "initial hurdle". I know both systems very well, and Mercurial gets in my way far, far more than Git.
charlesmarshall 16y ago
not all guis are made equal, depends which is being used to how good or bad it is. I use gitx on osx (http://gitx.frim.nl/ http://gitx.frim.nl/), other than the lack of a 'push' button its spot on, simple to use and powerful.
j_baker 16y ago
git's interface isn't terribly intuitive, but it isn't that bad. Once you get the hang of it, it makes sense.
- anthonyb 16y ago
  I really don't follow this argument. git's interface is a giant turd. I've been using it for months, and it still hasn't stuck, no matter what tutorials I read. The normal workflow needs far too many commands and special options, local vs. remote branching seems to do weird things, and the error messages are completely obtuse.
njharman 16y ago
Yeah, I too thought the logic of that statement was completely back asswords.

mbrubeck 16y ago

I've used Git for three years, at two different companies and various personal and community projects. I sync my home directory between hosts using git, I have administered multi-user git repos using gitosis, and I have been a GitHub user since early 2008. I started using Mercurial two months ago when I joined the Mozilla corporation, and now use it every day on one of the biggest and best-supported installations in the world. I also started using BitBucket for some of my Mozilla-related personal projects. It might be that I don't fully "get" Mercurial yet, but I still find myself frequently missing Git. My first impression is that Git has a simple flexible model that supports a complex front-end, while Mercurial has a simple extensible front-end that ends up creating a somewhat more complicated model. Any time I need to step outside the standard commit-merge-push workflow, I find the higher level of abstraction between Mercurial's user commands and its database makes it harder to understand what I'm doing, and sometimes prevents me from doing what I want. Things like rewriting history (e.g. for rebasing), or combining changes from multiple remote repos with different sets of branches, are still possible in Mercurial - but they usually require plugins to do well, there are more different incompatible ways to do them, and there are more opportunities to mess up your repo. More concretely, I find that MQ is the best way to do many tasks in Mercurial that I would do in git with plain old branches and commits, and for many of these uses MQ is both more complicated and less flexible than the equivalent git commands. (But there are other uses where MQ is really better than the alternatives.) I also find that it's much more annoying to manage short-lived throwaway or topic branches in Mercurial, so much that I simply avoid using them much of the time. But perhaps I'm just brainwashed (or brain-damaged) from too many years with Git. :)

sreque 16y ago
For creating temporary local branches, have you tried the bookmarks and localbranch extensions? Also, I am be interested to learn more about your workflow and why it is so difficult to do in Mercurial. So far, the only feature I've seen in git that I've wanted in Mercurial is the ability to manage publicly named branches using the bookmarks extension, and by extension, an easy way to track named branches.
jwr 16y ago
Good point about MQ, before people pointed me to it, I was continuously surprised by many things I could not easily do in hg. The DVCS crowd looks down on centralized VCSses and points out that whenever the answer to a VCS question begins with "well, you should have done X before you did this…", it marks a failure. Fair enough. But I would extend that further — when I ask "how do I do X with this VCS", I don't want to be told "well see, you don't really want to be doing X". Yes I do want to, and I want a VCS that let's me do pretty much anything I want. That's git's approach.

psranga 16y ago

I thought Git handled huge files poorly too. What I'd read was that most algos in git assume that the whole file in revision control can be held in memory at once to do things like diff. Has this changed, or was I always mistaken, or this guy talking about the sum of file sizes being a few gig?

sandGorgon 16y ago
I cant find the resource, but sometime back someone compared DVCS for large binary files (game assets) and saw they were absolutely inefficient .. and in several case incapable of handling large files
avar 16y ago
It still handles them poorly by default. You can do things like edit .gitattributes to say that e.g. a *.binary file should be treated specially, but Git's still not a good system for e.g. archiving HD video. Some of this can be fixed, but a lot of it is probably not going to change. When you git-add something it has to checksum the old data + new data. That's going to be a pretty expensive operation when you have 50TB of data. There's no DVCS that I'm aware of that handles large binary files as well as say Perforce or Subversion. Check out this project for more info on tuning Git for big files: http://caca.zoy.org/wiki/git-bigfiles http://caca.zoy.org/wiki/git-bigfiles

avar 16y ago

This is always relevant: http://keithp.com/blogs/Repository_Formats_Matter/ http://keithp.com/blogs/Repository_Formats_Matter/ "I would like to argue that none of the user-interface and high-level functional details are nearly as important as the fundamental repository structure. When evaluating source code management systems, I primarily researched the repository structures and essentially ignored the user interface details. We can fix the user interface over time and even add features. We cannot, however, fix a broken repository structure without all of the pain inherent in changing systems." Keith makes a good point. While Git's interface is lacking in some areas, those things can be fixed in the higher level porcelain. Picking a system with a nicer interface whose plumbing is uglier will lead to problems further down the road.