Hacker News new | ask | show | jobs
by jorams 948 days ago
> Originally, separate clones was the recommended way to do "topic branches" in Mercurial

This is still what the Guide on the Mercurial site mentions as the "basic workflow" for working on separate features. Named branches are considered "advanced", and bookmarks are an afterthought entirely.

About 10 years ago, after reading a lot about how hg was more intuitive than git, I decided to give it a try. I was already using git branches a lot, so this was definitely not a good first impression.

3 comments

People like to say that github is the reason git won the dvcs wars 10 years ago, but I think this is it. I think a lot of people's first impression of git back in the day was making a local mirror of their company's svn using git-svn. Without local branches this was a pointless exercise but with git you still got some benefit even without the remote being a git repository.
Back in the day I was doing some GCC development while upstream was still using SVN. At that time there was both Hg and Git mirrors, and while the GCC repo isn't that huge in the grand scheme of things, it's big enough that the "standard" hg workflow of having a separate checked out tree for every local branch you're working on was definitely painful. While I had been using hg for some personal projects, this was really the killer feature that drove me to git.
> This is still what the Guide on the Mercurial site mentions as the "basic workflow" ...

I imagine you're referring to the "hg book"[1] ?

It irks me that that site hasn't been updated since ~2009, and there doesn't seem to be anything equivalent for "modern" Mercurial. Alas.

EDIT: oh, looks like there is a somewhat newer version (~2015?): https://book.mercurial-scm.org/read/part-getting-started.htm...

[1] http://hgbook.red-bean.com/

> I imagine you're referring to the "hg book"[1] ?

No, I mean when you go to the site and click the second item in the menu, Guide[1].

[1]: https://mercurial-scm.org/guide

Separate clones are basically exactly like forks on GitHub, which is pretty standard these days. Seems they were ahead of the curve (again).
You don't make multiple forks of a project if you want to PR multiple separate changes though (github doesn't even allow it). And, on top of that, last I heard, forks in github are actually implemented as git branches. :)