Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial 2.9 released

mercurial.selenic.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Mercurial 2.9 released

#41

Post by grey413 »

notwedtm wrote: post #2

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

Four reasons, all dating back to when I started using VC.

1) The GUIs were better, especially on windows. I think that gap has closed some in the last few years, but I think hg still has an edge.

2) Bitbucket offered free private repos and was hg only when they started out

3) The command line semantics were less imposing

4) I happened to find some really good introductory literature for hg.

I was a very, very green developer at the time so all of these points mattered a lot.

Re: Mercurial 2.9 released

#42

Post by enscr »

ender7 wrote: post #27
pekk wrote: 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…

This is precisely the reason I couldn't force myself to use Git. The UI of Mercurial is so much more consistent and intuitive. I find it easier for non-technical people in the company to share files.

Re: Mercurial 2.9 released

#43

Post by kyrra »

yapcguy wrote: post #10
nilved wrote: 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.

But being more popular is a reason groups will pick it. See Emacs's discussion on moving away from BZR [0]. While there are some people that like HG, Git popularity brings some benefits with it.

A larger user base and a large number of companies using it mean that there will be more investment in the tool. So there is a variety of companies that invest in it. There is a smaller chance development will stop on Git compared to HG. So basically the Emacs team concluded they don't want to be stuck with another BZR, and Git seems like a safer choice.

A variety of companies have bet on HG, but decided they needed to support Git along side it to get more sales (Fog Creek and Atlassian).

I feel like Github was the deciding tech that made Git the more popular code. There are a number of other companies supporting HG still, so it won't go away anytime soon, but it's hard to say if it'll be here as long as Git.

[0] http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg000...

Re: Mercurial 2.9 released

#44

Post by gtaylor »

jgalt212 wrote: post #28

Has anyone used this (or something similar)? the Hg-Git mercurial plugin http://hg-git.github.io/

I've tried to use it to mirror an old Hg repo in git, but ran into some really weird errors with branches in Hg causing vague errors. I couldn't get any help on the mailing list, and I ended up giving up right as the project said "Forget it, let's just move to Git."

This was about six months ago. I don't have the error message. I got the impression that the documentation and the support were pretty sparse for this plugin. Though, it may work well for more simple Hg repositories, I guess.

Re: Mercurial 2.9 released

#45

Post by dscrd »

notwedtm wrote: post #2

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

I got used to how hg works and now, in comparison, git always confuses the hell out of me with its unintuitive commands and odd walls-of-text errors.

Re: Mercurial 2.9 released

#46

Post by Skinney »

toggle wrote: post #11
notwedtm wrote: post #2

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

For me, it's: 1. The queues extension. 2. A bazillion other extensions. 3. The source code is pretty reasonable -- even mortal humans can contribute and write their own extensions. I've found the queues extension to be really useful. It's like having multiple staging areas, which will later become multiple commits. I tend to change too many things, and then remember that I need to create specific commits. Queues make…

git stash?

Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.

Re: Mercurial 2.9 released

#47

Post by Skinney »

mamcx wrote: post #22
notwedtm wrote: post #2

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

I consider hg far more easy to use than git, specially for the most used commands (status, fetch, push). I need to check the docs about how do the damm push each time with github. My only gripe with mercurial? That everyone else asume git.

check the docs? What is so hard to remember about "git push"?

Re: Mercurial 2.9 released

#48

Post by mintplant »

pavanky wrote: post #29
ender7 wrote: post #27

Earlier quoted context omitted.

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

...shouldn't be necessary, and won't be in place for someone just starting out.

Re: Mercurial 2.9 released

#49

Post by Silhouette »

ngoldbaum wrote: post #21
pbreit wrote: post #16

The monthly updates always scare me a bit for version control. Is that really prudent?

They're actually very big on backwards compatibility. It's quite straightforward to work with repositories created by old mercurial versions on and communicate with mercurial installs with different versions. The only thing that won't work is features that are only in the newer version. The real effect of the monthly releases is that bugs get cixed in releases, new features get added, and I get to regularly see all o…

This is something that has always made us a little nervous about updating here as well. Do you know whether the underlying data structures for repositories are generally maintained with both forward and backward compatibility?

Edit: For anyone else interested, I finally found the magic search term I never had before, which led me to this page about upgrading and compatibility:

http://mercurial.selenic.com/wiki/UpgradingMercurial

and this page about potentially breaking changes where they do occur:

http://mercurial.selenic.com/wiki/UpgradeNotes

The short version is that older and newer Hg clients and servers and mostly interoperable in all directions, but with a few specific caveats that are worth reading before you upgrade anything. There is also the ability to explicitly change the underlying repository format for compatibility reasons if you need to.

Re: Mercurial 2.9 released

#50

Post by shawnz »

adharmad wrote: post #34
ender7 wrote: post #27

Earlier quoted context omitted.

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

As far as I am concerned, the gap in power between git and hg is much smaller than the gap in ease of use. The ease-of-use argument is only countered when there is real value to using the more frustrating alternative, and I'm not sure there is with git (besides the existence of GitHub, and the support of Linus Torvalds).
Post reply on HN