Personally all my own projects are on bitbucket. They were the first to provide free unlimited private repos and just has a great set of tools. So my personal preference is bitbucket over github.

They also support Mercurial, which I personally find to be a way better scm tool than git.

Not trying to start the classic hg vs git debate, just saying that it's great to have the option.

It's not better, it's just a million times more usable. A Ferrari is nice, but for day-to-day stuff I'd rather use a Volvo :)

The trick to git is figuring out the subset of commands that make it work like a Volvo

Why do that if you could just use hg?

Because everyone else is still using git.

There is a Mercurial extension that allows you to use hg commands to interact with a git repo

https://bitbucket.org/durin42/hg-git

My experience with hg-git has been that it is not always a great citizen with git repos and it can cause something of a mess. (This is a few years old now, because like the rest of the world I switched to git; it may have improved in the meantime.)

For some reason the enterprise version doesn't support mercurial, it's only git.

The reason is it's a completely unrelated product (previously known as "stash") that Atlassian pretends is somehow connected for branding reasons.

Yep, the two products are even written in separate languages!

Bitbucket Server is written in Java and bitbucket.org is written in Python.

I was dumbfounded when I found out they were two separate codebases.

I thought it's like JIRA. Or is JIRA self hosted also different from the cloud version?

I don't understand what you mean by "like JIRA". Remember all these Atlassian products have been acquired as what were originally separate companies.

...grumble grumble...Skype for Business...OneDrive for Business...

(hate it when companies do this)

It's because mercurial is legacy, like darcs, bzr, monotone, and the other zoo of "git-alikes" that were big in 2008. Now it's just like MacOS Classic in 2000: there are a few die-hard zealots who claim that the interface is better in some indescribable way, and everyone else has moved on.

Does this look like the commit log of a legacy product?

https://www.mercurial-scm.org/repo/hg/

Mercurial is very important for Facebook, Mozilla, Google, and others. The disparaging "legacy" monicker might be a good way to feel justified to not have to learn about it, but it's not dying software that is no longer getting updates.

Speaking as someone that works with Mercurial on daily basis, and also makes/sells software that supports Mercurial. I can tell you it's far from beeing legacy.

Some people work with COBOL on a daily basis. It's still antiquated.

What determines if a technology is considered legacy is not if there exists someone out there using it, but rather whether there are people actively adopting it at present. In this regard, Mercurial has slowed down and Git has clearly won the game.

There are companies adopting mercurial as they VCS of choice, either by moving out of svn, or choosing a new VCS

Bitbucket server is written in Java while Bitbucket.com in Python. Those are two different products. That's why the Enterprise version supports only GIT.

Check our RhodeCode for Enterprise SCM tool that supports Mercurial too.

Is RhodeCode still Pylons or have to migrated to Pyramid?

It's now based on pyramid 1.6

Atlassian has cracked the enterprise sales nut completely. Github is still struggling with it some. Completeness is a big reason for that.

And I hope GitHub stays incomplete! I don't need hierarchical access control to decide who can add, remove, and list issue labels, or whatever, just because some pointy-haired enterprise boss came up with that idea five minutes ago.

I hear you, but a simple folder system sure would be nice. Not organizations, just: Client/Project

Nice and simple.

Yeah, and Bitbucket sucks in any other conceivable way, so I don't see why it should be a competitor other than that they shove it in your face once you want to use JIRA or Confluence.

Jira apparently has a reasonable set of Agile tools, with card decks and all.

I suppose that what they are buying, among other things, is a significant paying customer base. These customers can be sold more products, e.g. Bitbucket / Bamboo, provided that Trello integrates with them well enough, or will in the future.

Yah, we're fighting this too. We have back and forth with various devs on our team - some use github, we all have to use Tracker.

Just curious as to what you think Github could do to fix this. I have a list of wishes and I'm always curious what other people have.

We are using https://www.zenhub.com/

GitHub + ZenHub work great.

* ZenHub - Agile GitHub Project Management Software || https://www.zenhub.com/

GitHub + Marker for bugs.

* Marker - Visual Feedback & Bug Reporting Tools for Web Professionals || https://getmarker.io/

GitHub + Unito + Asana even... for clients to get some pretty dashboards without getting bogged down... this works great too.

* Unito - Connect your project management tools and become your team's collaboration hero || https://unito.io/

I love how many things play nice with GitHub now.

Out of curiosity, what are the things you don't like with Github issue tracker?

Personally (and I'm not sure if JIRA fixes this, but Trello gets around it), the biggest issue I have is that Github treats repositories as the only possible context. Say a bug comes in that covers multiple repositories (e.g.: requires a mobile app fix and a backend fix), then you need to create two completely seperate issues and remember to link them manually. This breaks down very quickly. I would much rather issues to optionally exist at an organisation level, with per-repository sub issues stemming from that organisation-level issue.

It also means that someone submitting bugs, say from customer support, must try and figure out where the issue is in order to log it. It's a huge hassle and most just give up and ping an engineer on Slack which is incredibly inefficient.

Trello gets around this by letting you create a "master" issue and link to the individual repository issues. It means engineering can have a bug inbox and triage from there. Still a huge pain and not ideal.

Github also has the "Projects" feature, but it is useless IMO due to the above issue - I wish projects would work at an organisation level.

Where I work you put a jira id in the commit message and it will automatically put a link to the commit in the jira ticket. And a jira ticket can link to multiple commits across multiple repos.

You can use GitHub Projects at organization level now.

https://github.com/blog/2272-introducing-projects-for-organi...

You can create organization-wide projects that are not repository specific with GitHub.com.

GitHub issue tracker is free, treat it like that ..