11 ms·

I think it's strange that Git seems more popular. Mercurial is a great tool. Also check TortoiseHg. Edit: I didn't want to start a flamewar. I'm just wondering

by ohwp 13y ago

I think it's strange that Git seems more popular. Mercurial is a great tool. Also check TortoiseHg. Edit: I didn't want to start a flamewar. I'm just wondering why Git seems more popular because I think both tools are very good.

mitchty 13y ago
Github + Linux kernel I think would be the primary drivers for that. Mercurial is fine, but its hard to ignore inertia. Similar to FreeBSD/Linux.
- EnderMB 13y ago
  Absolutely, in the same way that some companies went for Mercurial simply because BitBucket (at the time) offered free private repositories and only supported Hg. Now, BitBucket support Git repos, and I've noticed a few companies I've worked at that are starting to move towards Git on BitBucket, probably because it's the more popular choice and more people will know it because of GitHub. I use both Hg and Git at work, and to be honest for my basic workflow there are very few noticeable differences in day-to-day work.
  - jff 13y ago
    I use git on bitbucket for all my personal stuff, because by signing up with a .edu email account, they gave me free unlimited private repositories. Sold. My only concern would be that people are finding my mostly-bare github profile instead, since that rules the hivemind.
    - EnderMB 13y ago
      Ha, you're not alone there! Hell, the only reason I have projects on my GitHub profile are because I felt scared about having a bare public profile linked to my real name. Mine still looks a bit stupid, because I'm a .NET dev with three Java projects from uni, and a Python blog written for Google App Engine.
- garenp 13y ago
  Totally agree with the first point in particular. The only reason I started using git is because it's required for github. Otherwise I'd use Mercurial exclusively.
bluedino 13y ago
Git has Linus, Linux, and Github behind it.
- hugi 13y ago
  Github was the only reason I switched to Git from Mercurial.
- tootie 13y ago
  Linus doesn't work on git anymore and I don't see what Linux has to do with anything. GitHub is to me the main reason for the success of git which I've discovered is incredibly difficult to use without GitHub. BitBucket good for me.
  - taspeotis 13y ago
    > Linus doesn't work on git anymore and I don't see what Linux has to do with anything Linus works with git because Linux kernel development uses git. You have, by default, thousands of pretty savvy developers working with git.
taeric 13y ago
The implication appears to be that Mercurial is better. Is it?
- StavrosK 13y ago
  I find Mercurial's porcelain more intuitive than git's, yes.
  - rrrene 13y ago
    Could you elaborate on this? Do you mean CLI/UI?
    - StavrosK 13y ago
      Yes, I haven't used Mercurial too extensively (I use git), but Mercurial's commands make more sense to me. The only problem I have with it is that conflicts throw me into vim, and if I exit it to try and make sense of the merges, it thinks I'm done merging and leaves me in an unreasonable state, whereas git just marks the files and lets me resolve them at my leisure.
      - durin42 13y ago
        You probably need to disable a merge tool. Check 'hg showconfig merge-tools' and you'll probably find something. If this is on a debian derived system, I think that package maintainer turns on a bunch of stuff by default, so you may need to find a file in /etc/hg or similar.
      - hrydgard 13y ago
        Not that I use hg anymore, but if I remember correctly, exiting vim with :cq (returning an error code) solves that.
        StavrosK 13y ago
        That's very interesting to know in general, thank you.
Silhouette 13y ago
Mercurial is great at many things, but surprisingly, it seems quite awkward to set up a shared repository on your network for multiple users. It doesn't come as standard with a simple, self-contained server, and they recommend against using a shared directory on a network drive directly, presumably because of the wicked data loss bugs they've had (or may still have, I haven't checked this recently). Compare the Mercurial guidance on publishing repositories[1], which comes in at about 15 screens on my system, with the equivalents for say Git[2] or Bzr[3] that fit in a couple of screens, and you can see how striking the difference is. [1] http://mercurial.selenic.com/wiki/PublishingRepositories http://mercurial.selenic.com/wiki/PublishingRepositories [2] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-... [3] http://doc.bazaar.canonical.com/bzr-0.11/server.htm http://doc.bazaar.canonical.com/bzr-0.11/server.htm [Edit: Rephrase to avoid sounding unintentionally trollish. I'm trying to answer the question, not start a flame war.]
- durin42 13y ago
  The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Note that on the Mercurial wiki page you linked, it does mention ssh setup, although perhaps not as prominently as you'd like. Also, hg /does/ come with a simple, self-contained server: hg serve. It doesn't support authentication, because there's a bunch of http servers that can do that for you better and with less bugs than we'd inevitably have.
  - Silhouette 13y ago
    The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Except that if you're running Windows rather than Linux, they don't. I have literally just tested it to make sure I'm not imagining things. The difference is that with Git you probably also have Git Bash installed on Windows, which while somewhat clunky does at least provide a fairly standardised mechanism for setting up keys etc. To my knowledge, there is no equivalent for Hg, and attempting to use hg with an ssh:// path to the repository seems to depend on what other software you have installed (Tortoise*, for example). If you know better, my team and I would love to learn something. This has been bugging us for years and across multiple projects, and none of us has ever found a simple, effective way of doing it. For the record, the mention of SSH setup on the page I linked to is literally just that: a mention, with no further details at all, and as noted above the obvious change of specifying an ssh:// path to a repository instead of a local one doesn't work by default on Windows. There's also a second entry for "Shared SSH", but that goes to a separate page describing half a dozen components that mostly aren't included with hg out of the box and again seem to lack much documentation in some cases. [Edit: Yes, there is also hg serve, but as you point out it lacks even basic security checks, and even the main Mercurial web site doesn't recommend relying on hg serve for more than temporary purposes.] [Edit 2: Rephrase to clarify shared SSH details.]
japaget 13y ago
The lack of any way to preserve file timestamps has made git a total non-starter for me. Mercurial has the TimestampMod extension (http://mercurial.selenic.com/wiki/TimestampModExtension http://mercurial.selenic.com/wiki/TimestampModExtension).
- bitwalker 13y ago
  I'm curious why you need to preserve the timestamps. I'm not saying it doesn't make sense, I just haven't ever had a time where that's been a requirement.
- saidajigumi 13y ago
  I'm really curious about your use-case. Are you just looking to tweak the behavior of the VCS w.r.t. a timestamp-sensitive build system? I will say that file timestamps invoke horrible, horrible memories of an employer that used Visual Source[un-]Safe -- a VCS that relied on accurate client system time for history integrity. I.e. the repo was easily corrupted if a client wasn't on synchronized time. Also, race conditions. AFAICT, it met none of the conditions casually denoted by the words "Version Control System".
- jlgreco 13y ago
  It should probably be pretty trivial to roll together a TimestampMod equivalent using a similar methodology as git-notes. Hell, just store a git-note for every commit in a non-standard ref; each note would have a printout of the tree and corresponding timestamps. To reapply timestamps, you'd just have touch run through the git note, re-touching every file to have the appropriate timestamps. Like others have said though, I don't understand what a use case for this would be. The page for that Hg plugin seems to indicate that it is just meant to ease the transition to version control, for users who don't yet 'get it'.
conductor 13y ago
There is another very underrated DVCS called Fossil (open source, C) - http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
poweribo 13y ago
As a very good alternative to TortoiseHg, I find Atlassian's SourceTree to have better UI experience. sourcetreeapp.com
rbanffy 13y ago
> Also check TortoiseHg. One company I worked for chose Hg instead of Git precisely because it had better Windows support. One year and one acquisition later, every developer was on either Linux or OSX and everyone was asking why did we go for Hg if Windows was not a concern...

by ohwp 13y ago

mitchty 13y ago

Github + Linux kernel I think would be the primary drivers for that. Mercurial is fine, but its hard to ignore inertia. Similar to FreeBSD/Linux.

EnderMB 13y ago
Absolutely, in the same way that some companies went for Mercurial simply because BitBucket (at the time) offered free private repositories and only supported Hg. Now, BitBucket support Git repos, and I've noticed a few companies I've worked at that are starting to move towards Git on BitBucket, probably because it's the more popular choice and more people will know it because of GitHub. I use both Hg and Git at work, and to be honest for my basic workflow there are very few noticeable differences in day-to-day work.
- jff 13y ago
  I use git on bitbucket for all my personal stuff, because by signing up with a .edu email account, they gave me free unlimited private repositories. Sold. My only concern would be that people are finding my mostly-bare github profile instead, since that rules the hivemind.
  - EnderMB 13y ago
    Ha, you're not alone there! Hell, the only reason I have projects on my GitHub profile are because I felt scared about having a bare public profile linked to my real name. Mine still looks a bit stupid, because I'm a .NET dev with three Java projects from uni, and a Python blog written for Google App Engine.
garenp 13y ago
Totally agree with the first point in particular. The only reason I started using git is because it's required for github. Otherwise I'd use Mercurial exclusively.

bluedino 13y ago

Git has Linus, Linux, and Github behind it.

hugi 13y ago
Github was the only reason I switched to Git from Mercurial.
tootie 13y ago
Linus doesn't work on git anymore and I don't see what Linux has to do with anything. GitHub is to me the main reason for the success of git which I've discovered is incredibly difficult to use without GitHub. BitBucket good for me.
- taspeotis 13y ago
  > Linus doesn't work on git anymore and I don't see what Linux has to do with anything Linus works with git because Linux kernel development uses git. You have, by default, thousands of pretty savvy developers working with git.

taeric 13y ago

The implication appears to be that Mercurial is better. Is it?

StavrosK 13y ago
I find Mercurial's porcelain more intuitive than git's, yes.
- rrrene 13y ago
  Could you elaborate on this? Do you mean CLI/UI?
  - StavrosK 13y ago
    Yes, I haven't used Mercurial too extensively (I use git), but Mercurial's commands make more sense to me. The only problem I have with it is that conflicts throw me into vim, and if I exit it to try and make sense of the merges, it thinks I'm done merging and leaves me in an unreasonable state, whereas git just marks the files and lets me resolve them at my leisure.
    - durin42 13y ago
      You probably need to disable a merge tool. Check 'hg showconfig merge-tools' and you'll probably find something. If this is on a debian derived system, I think that package maintainer turns on a bunch of stuff by default, so you may need to find a file in /etc/hg or similar.
    - hrydgard 13y ago
      Not that I use hg anymore, but if I remember correctly, exiting vim with :cq (returning an error code) solves that.
      - StavrosK 13y ago
        That's very interesting to know in general, thank you.

Silhouette 13y ago

Mercurial is great at many things, but surprisingly, it seems quite awkward to set up a shared repository on your network for multiple users. It doesn't come as standard with a simple, self-contained server, and they recommend against using a shared directory on a network drive directly, presumably because of the wicked data loss bugs they've had (or may still have, I haven't checked this recently). Compare the Mercurial guidance on publishing repositories[1], which comes in at about 15 screens on my system, with the equivalents for say Git[2] or Bzr[3] that fit in a couple of screens, and you can see how striking the difference is. [1] http://mercurial.selenic.com/wiki/PublishingRepositories http://mercurial.selenic.com/wiki/PublishingRepositories [2] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-... [3] http://doc.bazaar.canonical.com/bzr-0.11/server.htm http://doc.bazaar.canonical.com/bzr-0.11/server.htm [Edit: Rephrase to avoid sounding unintentionally trollish. I'm trying to answer the question, not start a flame war.]

durin42 13y ago
The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Note that on the Mercurial wiki page you linked, it does mention ssh setup, although perhaps not as prominently as you'd like. Also, hg /does/ come with a simple, self-contained server: hg serve. It doesn't support authentication, because there's a bunch of http servers that can do that for you better and with less bugs than we'd inevitably have.
- Silhouette 13y ago
  The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Except that if you're running Windows rather than Linux, they don't. I have literally just tested it to make sure I'm not imagining things. The difference is that with Git you probably also have Git Bash installed on Windows, which while somewhat clunky does at least provide a fairly standardised mechanism for setting up keys etc. To my knowledge, there is no equivalent for Hg, and attempting to use hg with an ssh:// path to the repository seems to depend on what other software you have installed (Tortoise*, for example). If you know better, my team and I would love to learn something. This has been bugging us for years and across multiple projects, and none of us has ever found a simple, effective way of doing it. For the record, the mention of SSH setup on the page I linked to is literally just that: a mention, with no further details at all, and as noted above the obvious change of specifying an ssh:// path to a repository instead of a local one doesn't work by default on Windows. There's also a second entry for "Shared SSH", but that goes to a separate page describing half a dozen components that mostly aren't included with hg out of the box and again seem to lack much documentation in some cases. [Edit: Yes, there is also hg serve, but as you point out it lacks even basic security checks, and even the main Mercurial web site doesn't recommend relying on hg serve for more than temporary purposes.] [Edit 2: Rephrase to clarify shared SSH details.]

japaget 13y ago

The lack of any way to preserve file timestamps has made git a total non-starter for me. Mercurial has the TimestampMod extension (http://mercurial.selenic.com/wiki/TimestampModExtension http://mercurial.selenic.com/wiki/TimestampModExtension).

bitwalker 13y ago
I'm curious why you need to preserve the timestamps. I'm not saying it doesn't make sense, I just haven't ever had a time where that's been a requirement.
saidajigumi 13y ago
I'm really curious about your use-case. Are you just looking to tweak the behavior of the VCS w.r.t. a timestamp-sensitive build system? I will say that file timestamps invoke horrible, horrible memories of an employer that used Visual Source[un-]Safe -- a VCS that relied on accurate client system time for history integrity. I.e. the repo was easily corrupted if a client wasn't on synchronized time. Also, race conditions. AFAICT, it met none of the conditions casually denoted by the words "Version Control System".
jlgreco 13y ago
It should probably be pretty trivial to roll together a TimestampMod equivalent using a similar methodology as git-notes. Hell, just store a git-note for every commit in a non-standard ref; each note would have a printout of the tree and corresponding timestamps. To reapply timestamps, you'd just have touch run through the git note, re-touching every file to have the appropriate timestamps. Like others have said though, I don't understand what a use case for this would be. The page for that Hg plugin seems to indicate that it is just meant to ease the transition to version control, for users who don't yet 'get it'.

conductor 13y ago

There is another very underrated DVCS called Fossil (open source, C) - http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

poweribo 13y ago

As a very good alternative to TortoiseHg, I find Atlassian's SourceTree to have better UI experience. sourcetreeapp.com

rbanffy 13y ago

> Also check TortoiseHg. One company I worked for chose Hg instead of Git precisely because it had better Windows support. One year and one acquisition later, every developer was on either Linux or OSX and everyone was asking why did we go for Hg if Windows was not a concern...