Earlier quoted context omitted.
Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: GitHub is why git won, and people are still learning how terrible git is and how awesome Mercurial is. They don't "still use" Mercurial, they "still use" git. Mercurial has a great API. git has a terrible API. Mercurial is a joy to extend in Python. git is impossible to extend to any meaningful degree and is a terri…
I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.
Mercurial 2.9 released
31–40 of 79 posts
Re: Mercurial 2.9 released
#32Earlier quoted context omitted.
Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager ( http://www.scm-manager.org/ ), which is free, supports both Hg…
> Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). You can do the same in git: git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/ or git daemon --verbose --export-all --base-path=. --reuse…
Re: Mercurial 2.9 released
#33Earlier quoted context omitted.
Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager ( http://www.scm-manager.org/ ), which is free, supports both Hg…
> If one needs to set up a local repo hosting service for internal use in a .NET company, There's also (shameless plug follows) HgLab ( http://hglabhq.com/ ).
Re: Mercurial 2.9 released
#34Earlier quoted context omitted.
What a contentless comment. One might just as well flatly claim that mercurial isn't nice for anything.
git's CLI design is byzantine and inconsistent, with terms that are both overloaded and underloaded (many commands do multiple, unrelated things while at the same time many common tasks do not have commands). It's very easy for newcomers to place their local repo into a limbo or failure state that they can't get out of without consulting a git guru. git's error messages and man pages are written for its developers, n…
To some extent, the same arguments can be used by newbies against any powerful tool (such as vim).
Re: Mercurial 2.9 released
#35Earlier quoted context omitted.
I like git because it stores objects, not diffs and you can recover from almost anything with reflog.
> I like git because it stores objects, not diffs Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]? [1]: http://git-scm.com/book/en/Git-Internals-Packfiles
Re: Mercurial 2.9 released
#36Re: Mercurial 2.9 released
#37I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.
Speed and workflow, previously. Mercurial has made up most of the difference in speed, so now git is better for some things ([temporary] topic branch workflow and history clean-up of such branches before merge is more likely to be used by git committers even if hg technically has that now, speed in a few cases, mindshare) while mercurial is better for other things like syntax, or dealing with gigantic repositories --…
Re: Mercurial 2.9 released
#38I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.
Re: Mercurial 2.9 released
#39I would LOVE to use mercurial. If the concept of a backup bundle was completely removed. When I amend a commit with git, I don't put myself 20 minutes away from recovering that pre-amend commit. If hg comes up with some way to have a flat namespace like git, (ideally with a reflog) I'll be back.
Re: Mercurial 2.9 released
#40I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.
* Linux Kernel : this means for once, great popularity. Those who commit to the kernel have quite a bit of say and influence in the industry. The tools they use get free marketing just from that. But this actually leads to the next reason -->
* Speed : initially git was quite a bit faster. It had been tested and benchmarked day to day on the kernel source tree. hg, bazaar and others weren't as performant back in the day.
* Github : this was the nail in the coffin of all the other DVCS-es as they say. It just came on time, with a nice interface,issues, easy to fork, do pull requests, markdown readmes etc. Not all rocket science features but it was just working very consistently and smoothly.
Now I liked bazaar better if I were not to compare them on performance back in the day. I like some of its centralization options, other things. But it is kind of too late in that sense. Launchpad should have appeared, say 6 months earlier, and it should have been smoking fast. It wasn't. And so my favorite DVCS was left behind. Bitbucket is also very nice. I really like it. But well all the cool kids are on Github so some projects just moved to that. I creates kind of mono-culture and I am not sure if it is good or bad yet.
At the end of the day there are 2 type of developers -- those who care about version control systems, read about them, play with them, and those that don't. This classification usually says nothing about other qualities, experience, personality traits etc. It is just the second group just cares to use it as a tool. They are willing to learn the minimum amount of command from a refcard to get their code committed. And having just one system means having one ref card only if they have to collaborate. So learning git/Github interface is the easiest way to proceed.