Live data from Hacker News

I'm going to slowly move on from Mercurial

mercurial-scm.org

41–50 of 165 posts

Re: I'm going to slowly move on from Mercurial

#41
post #12

Earlier quoted context omitted.

> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…

> Ouch, yet another way in which running on Windows can lead to poor technical decisions. I didn't see any indication in the parent comment (or in general, really) that Windows support was the cause of Mercurial's difficulty in implementing those features.

He means that Mozilla devs running Windows led them to adopt Mercurial (which was, in his opinion, a "poor technical decision"). Not that Mercurial made poor technical decisions as a result of supporting Windows.

Re: I'm going to slowly move on from Mercurial

#42

Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?

Re: I'm going to slowly move on from Mercurial

#43
post #3

Earlier quoted context omitted.

Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. Some git users relied on cogito for another year or so, as simple things like `git-commit` still had to be manually handcrafted out of `git-commit-tree`. I wasn't there to witness this, but I repeat it because it's actual…

> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…

> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each.

How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the files, or even a part of a file if you use the record extension.

Re: I'm going to slowly move on from Mercurial

#44
post #13

hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

hg came before git, you have your network effect backwards. The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly. Mercurial, in contrast, is "opinionated". (Before you mention github -- the timeline here is also backwards, github became…

I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.

Re: I'm going to slowly move on from Mercurial

#45
post #42

Earlier quoted context omitted.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?

Those would be accomplished with hg templates, not revsets. Revsets are kind of like gitrevisions(7), but much more powerful.

Docs:

https://selenic.com/hg/help/revsets

A complete example, which appears to have some popularity in Mozilla:

http://jordi.inversethought.com/blog/customising-mercurial-l...

edit: Sorry, the --decorate part would be with template, the --all is kind of like a revset, and the --graph part is well, --graph.

Re: I'm going to slowly move on from Mercurial

#46
post #42

Earlier quoted context omitted.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?

[deleted]

Re: I'm going to slowly move on from Mercurial

#47
post #42

Earlier quoted context omitted.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?

Usage without a PhD in git-manpage-generator, primarily.

Re: I'm going to slowly move on from Mercurial

#48
post #13

hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

Yeah by "git's network effects" you mean github. If github had decided to be hghub instead, hg would probably have won.

It seems github and bitbucket were released in the same year.

Re: I'm going to slowly move on from Mercurial

#49
post #42

Earlier quoted context omitted.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

What is it about these revsets that can't be achieved with a "git log --graph --decorate --all"?

[deleted]

Re: I'm going to slowly move on from Mercurial

#50

Earlier quoted context omitted.

> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…

> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the file…

> if you use the record extension.

It's now part of core with `hg commit -i`, although it's still experimental.

Post reply on HN