Live data from Hacker News

Mercurial 2.9 released

mercurial.selenic.com

31–40 of 79 posts

Re: Mercurial 2.9 released

#31
post #10
post #6

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.

I use Git because everyone else does. And I'm not ashamed of that; I think it's pragmatic. However, I think I would prefer if the crowd had converged on Mercurial instead.

Re: Mercurial 2.9 released

#32
post #3

Earlier 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…

AFAIK, this does not work with Git in Windows. I will try it at home where I have Lubuntu and see. (If it works, I'll make an alias for it.) Thanks.

Re: Mercurial 2.9 released

#33
post #3

Earlier 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/ ).

I was supposed to try this out after SCM Manager, but our IT admin has not replaced the server I was using after it broke. If I ever get access to one again, I'll try it.

Re: Mercurial 2.9 released

#34
post #27
post #19

Earlier 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…

> git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.

To some extent, the same arguments can be used by newbies against any powerful tool (such as vim).

Re: Mercurial 2.9 released

#35

Earlier 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

I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.

Re: Mercurial 2.9 released

#36
I 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

#37
post #23

I 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 --…

I think hg has both temporary (bookmarks) and permanent (branches) branch workflow out of the box now- and has for a while.

Re: Mercurial 2.9 released

#38
post #23

I 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.

It isn't _just_ GitHub, but it's 90% GitHub. And 10% Torvalds. The important part is that it's 0% actual, useful reasons.

Re: Mercurial 2.9 released

#39
post #36

I 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.

I wish I knew what you are talking about- it sounds useful. I use mercurial- I've never used git.

Re: Mercurial 2.9 released

#40
post #23

I 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.

3 reasons:

* 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.

Post reply on HN