5 ms·

I prefer Mercurial (Hg). I'm sure Git is the preferred choice amongst the alpha of alpha geeks, but for small and medium-sized projects, Hg's simple intuitive c

by lowkey 18y ago

I prefer Mercurial (Hg). I'm sure Git is the preferred choice amongst the alpha of alpha geeks, but for small and medium-sized projects, Hg's simple intuitive command structure, and more than adequate speed (2nd only to Git) is a God send. Git just seems overly complex for all but the most sophisticated workflows. I could be wrong, but that has been my experience.

schacon 18y ago
I would argue (as I do at the site there) that Git is just as easy to learn and use as Hg, in some cases easier (http://jointheconversation.org/2008/11/24/on-mercurial/ http://jointheconversation.org/2008/11/24/on-mercurial/). The 'Hg is easier' argument tends to be from those who initially tried Git a while ago.
mindaugas 18y ago
Actually I started using git just for fun and it was on windows. At first I used just graphical interface gittk. It was very easy and clear. I encourage every git newbie to try gittk. After using gittk "index thing" became a lot clearer. So what I'm trying to say is that Git is not some complex beast with dark powers. P.S. And I'm hardly an alpha geek or even power user.
sh1mmer 18y ago
This was my exact argument for Bazaar. After playing with Git 1.6 for a few minutes today all my usual commands work. It took me literally 3.5 minutes to get Git setup using the OSX install package and fixing my .profile to include the new path. I'm very impressed. Now if only Github had a trial membership with a Private repo...
- bprater 18y ago
  I'm in agreement with Github having a free/trial private repo. It's a huge oversight.
  - mojombo 18y ago
    GitHub is totally free and unrestricted for public code. This should give you plenty of freedom to try out the service without paying. Also, as a promotion for Cyber Monday, new signups today (12/1) can get a paid plan free for one month.
    - tsally 18y ago
      Because of this, I just signed up to try it. I'm going to be honest though: I wouldn't have without a private repository. I like to version control my homework, and obviously it's against school policy to publicly post solutions to homework. If this works out I'll end up paying for a micro plan, but I never would have even given GitHub an opportunity without a private repo. Of course, that's just my opinion. :-) You may not even be targeting students anyway.
- gcv 18y ago
  I thought github does allow private repositories on the free plan? Maybe something changed, but it used to allow a private repository, but you couldn't share it with anyone.
- jjburka 18y ago
  http://unfuddle.com/ http://unfuddle.com/ has free private repos and they support git
orib 18y ago
I'm reminded of Carl Worth's effort to port the HG guide to Git. It was mostly a search-replace effort, where the concepts were more or less the same, and the commands were similar.
utx00 18y ago
i prefer hg too. cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below) everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote. git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster. git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard. staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. distributed: yes. hg is distributed. that's why it has commands like incoming. any workflow: same thing in both. github: http://www.bitbucket.org/ http://www.bitbucket.org/ easy to learn: git is easier to learn than mercurial? ok, now here's what i don't like about git: storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed. bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git. index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git. documentation: better in hg. much better actually. git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far. in the end they both rock, but i prefer hg.
- silentbicycle 18y ago
  > if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. Very true. Mercurial's design puts most of its non-core functionality into extensions (which are easy to ignore if you don't need them), and has a clean setup for adding new extensions. How does git handle that? I haven't looked into the git source lately. And regarding "incoming", the article says that git has a separate command (fetch) for caching server data, i.e. if there are incoming patches, when connections are available. (According to git-fetch(1), fetch looks more like pull without updating/merging locally. Unless I'm misunderstanding things, the comparison to hg's incoming is probably a bit of a stretch.)

by lowkey 18y ago

schacon 18y ago

I would argue (as I do at the site there) that Git is just as easy to learn and use as Hg, in some cases easier (http://jointheconversation.org/2008/11/24/on-mercurial/ http://jointheconversation.org/2008/11/24/on-mercurial/). The 'Hg is easier' argument tends to be from those who initially tried Git a while ago.

mindaugas 18y ago

Actually I started using git just for fun and it was on windows. At first I used just graphical interface gittk. It was very easy and clear. I encourage every git newbie to try gittk. After using gittk "index thing" became a lot clearer. So what I'm trying to say is that Git is not some complex beast with dark powers. P.S. And I'm hardly an alpha geek or even power user.

sh1mmer 18y ago

This was my exact argument for Bazaar. After playing with Git 1.6 for a few minutes today all my usual commands work. It took me literally 3.5 minutes to get Git setup using the OSX install package and fixing my .profile to include the new path. I'm very impressed. Now if only Github had a trial membership with a Private repo...

bprater 18y ago
I'm in agreement with Github having a free/trial private repo. It's a huge oversight.
- mojombo 18y ago
  GitHub is totally free and unrestricted for public code. This should give you plenty of freedom to try out the service without paying. Also, as a promotion for Cyber Monday, new signups today (12/1) can get a paid plan free for one month.
  - tsally 18y ago
    Because of this, I just signed up to try it. I'm going to be honest though: I wouldn't have without a private repository. I like to version control my homework, and obviously it's against school policy to publicly post solutions to homework. If this works out I'll end up paying for a micro plan, but I never would have even given GitHub an opportunity without a private repo. Of course, that's just my opinion. :-) You may not even be targeting students anyway.
gcv 18y ago
I thought github does allow private repositories on the free plan? Maybe something changed, but it used to allow a private repository, but you couldn't share it with anyone.
jjburka 18y ago
http://unfuddle.com/ http://unfuddle.com/ has free private repos and they support git

orib 18y ago

I'm reminded of Carl Worth's effort to port the HG guide to Git. It was mostly a search-replace effort, where the concepts were more or less the same, and the commands were similar.

utx00 18y ago

i prefer hg too. cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below) everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote. git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster. git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard. staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. distributed: yes. hg is distributed. that's why it has commands like incoming. any workflow: same thing in both. github: http://www.bitbucket.org/ http://www.bitbucket.org/ easy to learn: git is easier to learn than mercurial? ok, now here's what i don't like about git: storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed. bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git. index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git. documentation: better in hg. much better actually. git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far. in the end they both rock, but i prefer hg.

silentbicycle 18y ago
> if one needs such a thing, there are mercurial queues. if you dont, it's not in your way. Very true. Mercurial's design puts most of its non-core functionality into extensions (which are easy to ignore if you don't need them), and has a clean setup for adding new extensions. How does git handle that? I haven't looked into the git source lately. And regarding "incoming", the article says that git has a separate command (fetch) for caching server data, i.e. if there are incoming patches, when connections are available. (According to git-fetch(1), fetch looks more like pull without updating/merging locally. Unless I'm misunderstanding things, the comparison to hg's incoming is probably a bit of a stretch.)