What's New in Mercurial 3.0 • Hacker News Board

Re: What's New in Mercurial 3.0

#21

Post by wirrbel » Tue, Apr 29, 2014, 8:55 PM UTC

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow.

Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just cant wrap my head around (granted I only use it occasionally).

As a platform I like how all the porcellain in mercurial is implemented in a high level python. I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.

Re: What's New in Mercurial 3.0

#22

Post by jordigh » Tue, Apr 29, 2014, 8:59 PM UTC

wirrbel wrote: post #21

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…

> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.

You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git.

The stdout of hg is guaranteed to remain stable, so you can script it by just parsing stdout. The options are guaranteed to remain stable, so your old tools won't need to be updated in case hg's CLI some day changes, because its CLI never changes.

There are also a bunch of hg CLI commands that start with debug (e.g. hg debugparents or hg debugdag) that you can use to directly manipulate hg's internal revlog data structure and do fun things like create a corrupt repo, if that's what you want to do. :-)

Re: What's New in Mercurial 3.0

#23

Post by ngoldbaum » Tue, Apr 29, 2014, 9:00 PM UTC

jordigh wrote: post #20

ngoldbaum wrote: post #19

Earlier quoted context omitted.

Sadly bitbucket does not have very good support for features from "modern" mercurial like bookmarks and changeset evolution. Since most of their users are git users I don't think they are strongly motivated to shore up mercurial support.

Their devs hang out in #mercurial in Freenode and have been talking about how to implement Evolve on the bitbucket WUI.

Good to know! I'm looking forward to more news on that front.

Re: What's New in Mercurial 3.0

#24

Post by mpdehaan2 » Tue, Apr 29, 2014, 9:08 PM UTC

scott_karana wrote: post #4

krallja wrote: post #3

Earlier quoted context omitted.

I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.

I agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere .

This is probably due to an understanding of rebases, rebases should be used to bring your commits to the top of the stack for easy review in OSS projects.

Amazingly useful for making sure patches are easy to apply while following a remote branch.

My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local branches more sane -- but it's frustrating because it's not the same thing.

Re: What's New in Mercurial 3.0

#25

Post by wirrbel » Tue, Apr 29, 2014, 9:10 PM UTC

jordigh wrote: post #22

wirrbel wrote: post #21

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…

> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface. You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git. The stdout of hg is guaranteed to remain stable, so you can…

I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.).

Any first hand experiences with this?

Re: What's New in Mercurial 3.0

#26

Post by BenefitOfDoubt » Tue, Apr 29, 2014, 9:14 PM UTC

Is Mercurial the BetaMax of source control? Better technically, but didn't have the promotion that Linus gave to Git when he copied much of what Mercurial and other systems had and added a bit of his own flavor.

Re: What's New in Mercurial 3.0

#27

Post by jordigh » Tue, Apr 29, 2014, 9:14 PM UTC

wirrbel wrote: post #25

jordigh wrote: post #22

Earlier quoted context omitted.

> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface. You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git. The stdout of hg is guaranteed to remain stable, so you can…

I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.). Any first hand experiences with this?

Sure. Here is a silly example that adds a lol() revset to Mercurial that fetches all prime revision numbers:

http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py

Re: What's New in Mercurial 3.0

#28

Post by Crito » Tue, Apr 29, 2014, 9:15 PM UTC

mpdehaan2 wrote: post #24

scott_karana wrote: post #4

Earlier quoted context omitted.

I agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere .

This is probably due to an understanding of rebases, rebases should be used to bring your commits to the top of the stack for easy review in OSS projects. Amazingly useful for making sure patches are easy to apply while following a remote branch. My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local bra…

Wait, "quilt" as in the tool that manages patch files? That's still in use? Or is quilt a new Hg extension?

Re: What's New in Mercurial 3.0

#29

Post by hugi » Tue, Apr 29, 2014, 9:16 PM UTC

wirrbel wrote: post #21

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…

As with most software, it probably depends largely on what you're used to. I started my distributed SCM life in Mercurial (moving from svn) and found it to be fast, simple and friendly to use. Being an experienced Mercurial user, I hated git when I first started using it - changing something as core to one's development life as the SCM isn't easy.

But after a while of working with both, you start seeing git and hg as relatively equal products, just with different UI quirks.

I eventually moved most of my projects to git, though. Not because I thought it was better, but because it was more widely used. And being the collaborative type, using git was the path of least resistance.

Re: What's New in Mercurial 3.0

#30

Post by jordigh » Tue, Apr 29, 2014, 9:19 PM UTC

mpdehaan2 wrote: post #24

scott_karana wrote: post #4

Earlier quoted context omitted.

I agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere .

This is probably due to an understanding of rebases, rebases should be used to bring your commits to the top of the stack for easy review in OSS projects. Amazingly useful for making sure patches are easy to apply while following a remote branch. My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local bra…

> and having to use things like quilt on top to try to make local branches more sane

I consider Mercurial Queues as one of Mercurial's youthful mistakes. It was ok in 2005, but we have much better things with bookmarks, histedit, and rebase and even with hg commit --amend.

Evolve is basically the last nail in MQ's coffin.