
Heptapod – Mercurial for Gitlab - mkj
https://heptapod.net
======
freedomben
Mercurial may not be popular, but the people that love it _really love it_.
There was much sadness when Bitbucket discontinued support. Maybe Heptapod is
a place those people can go.

~~~
hinkley
I wonder if anyone out there has an opinion on whether there is a smaller tool
inside of Mercurial waiting to break out, the way Firefox was a renaissance
for Mozilla.

~~~
Shish2k
That seems to imply there’s some problem with hg the tool, being big and
bloated? In my experience the tool is fine (quite a lot better than git, IMO)
- the problem is that distributed version control is all about community, and
the community uses git. Mercurial-the-tool would need to be 10x as good to get
people to consider leaving git’s community, and it’s only 2x as good, so they
don't.

------
dragonsh
It’s nice to see another option for mercurial. Heptapod will definitely help
given an integrated CI/CD.

In my startup everything is mercurial. It’s miles ahead of git when it comes
to user interface and experience with conceptual integrity.

Git is popular due to GitHub, for us we use self-hosted kallithea-scm [1] to
provide workflow with pull request and review similar to GitHub. So far didn’t
see the need to change, it’s just that we need to build our own small
extension to integrate with CI/CD (here also buildbot [2] is quite nice).
Another open source is sourcehut [3].

[1] [https://kallithea-scm.org/](https://kallithea-scm.org/)

[2] [https://buildbot.net/](https://buildbot.net/)

[3] [https://hg.sr.ht](https://hg.sr.ht)

~~~
sjellis
Sourcehut is a really well-engineered and well-run project. The architecture
is SCM-independent, so Mercurial is not disadvantaged.

The lead developer goes out of his way to support less-popular systems, such
as *BSDs and Mercurial, so if you work with more niche technologies, you may
find Sourcehut a good home for your projects.

~~~
beagle3
Sourcehut is indeed well engineered and well run, and also very opinionated -
which is actually great for most people.

However, if the opinions disagree with you -- e.g., if you need your builds to
run on Windows, you ARE disadvantaged. Which is not a bad thing - I wholly
support Drew's machine and opinions - but that's one of the reason I can't
promote it at $MY_DAY_JOB, where I can't drop the Windows requirement.

------
sytse
It is great to see people using GitLab to continue to use Mercurial now that
BitBucket deprecated it [https://bitbucket.org/blog/sunsetting-mercurial-
support-in-b...](https://bitbucket.org/blog/sunsetting-mercurial-support-in-
bitbucket)

~~~
sytse
They elaborated on their choice for GitLab on
[https://octobus.net/blog/2018-09-18-heptapod-
announce.html](https://octobus.net/blog/2018-09-18-heptapod-announce.html)

"Gitlab has been one of the fastest growing platforms in the past couple of
years. It has a strong feature set praised by many. We have seen all kinds of
users switching from Mercurial to Git just to be able to use it. So the
quality and the reputation of the product itself made us look into it.

Moreover, Gitlab has an open source version "Gitlab CE", provided under an MIT
license. They have a healthy community with significant external open source
contribution. It fits with our own open source philosophy and allows us to
directly hack on the product core to add support for Mercurial.

Also, other open source communities, Gnome and Debian, picked Gitlab as their
tool. Having such serious actors of the free software world trust Gitlab was
important in our choice."

------
BluSyn
Can someone enlighten me as to the advantage of sticking with Mercurial? I've
tried hg many times and personally found nothing compelling about it compared
to git workflows.

Git is ubiquitous, there's no _really_ important feature set that hg offers
over git, and it's super trivial to convert repos from hg -> git. So why go
through this effort?

Note: I'm not trying to start a flamewar; genuinely curious.

~~~
BeetleB
It. Just. Works.

The only people who are unhappy with Mercurial are git users. Everyone I know
who is coming from something else to Mercurial never have a desire to leave
it.

It has a lot (most, really) of the power of Git, but no one has found a need
to make an "Oh Shit Hg" site, because it's not trivial to screw up in it.

Because it has a separation between simple and advanced features (many of
which are disabled unless you explicitly enable them), you don't get people
wasting a lot of time trying to find the ideal workflow in Mercurial. In a
sense it's a bit like Perl vs Python. Perl has many ways to do the same thing.
Python is more opinionated, and has preferred ways of doing things. As a
result, a team of N Mercurial users will usually not have N different
workflows. In my current team, there's been a lot of thrash/arguments over the
workflow (rebase vs merge, squash vs not, linear vs branched history, history
rewriting vs not, etc).

The documentation, though, sucks. It's quite outdated.

~~~
rich_sasha
> you don't get people wasting a lot of time trying to find the ideal workflow
> in Mercurial.

Interesting. I’m keen on trying Mercurial, but one thing that has somewhat
confused me is the profusion of branch-like workflows. Named branches,
bookmarks, now also topics (or whatever it’s called), hidden commits etc.

Is there a good definitive guide somewhere on the best workflows for hg?

~~~
CaptainRefsmat
> Is there a good definitive guide somewhere on the best workflows for hg?

I don't know about workflows specifically, but there is a very good reference
[0] about Mercurial's branching models. Maybe this will help you.

[0] [https://stevelosh.com/blog/2009/08/a-guide-to-branching-
in-m...](https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-
mercurial/)

~~~
rich_sasha
Thanks for this. This is fairly old now though, and doesn't even mention
bookmarks (which I understand to be like git branches, except they aren't (?)
synched between repo copies. Then there's some new stuff that apparently are
very good, but I can't find a proper description of how they work / should be
used.

~~~
BeetleB
> This is fairly old now though, and doesn't even mention bookmarks.

What do you mean? It has a section on it:

[https://stevelosh.com/blog/2009/08/a-guide-to-branching-
in-m...](https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-
mercurial/#s6-branching-with-bookmarks)

(I have not audited to see how accurate the information is, though).

> Then there's some new stuff that apparently are very good, but I can't find
> a proper description of how they work / should be used.

Yes - I often wished that someone wrote and maintained an article listing all
the extensions that one likely will want to use.[1] One you may want to look
into is evolve.

[1] Maybe someone has written this - I haven't checked in the last few years.

~~~
rich_sasha
Ah my bad, missed it, you’re right.

------
eire1130
We use this. It's much better then bitbucket. We are a distributed team of
about 15ish devs. It has had some growing pains, but the support team is top
notch and extremely responsive.

------
taspeotis
It's your money, it's your time, sure do whatever you want! But it's not where
I'd invest my time or money [1].

[1]
[https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...](https://trends.google.com/trends/explore?date=all&q=%2Fm%2F012ct9,%2Fm%2F05vqwg,%2Fm%2F08441_)

~~~
yepthatsreality
> Heptapod is a community driven effort to bring Mercurial SCM support to
> GitLab™, started by Octobus, a company providing professional services
> around Mercurial.

What do search trends have to do with a community effort to bring fully
featured open source version control tool support to dev-ops management
software? Is your comment aimed at the sponsors?[0]

[0]
[https://heptapod.net/pages/sponsors.html#sponsors](https://heptapod.net/pages/sponsors.html#sponsors)

