Shipping hg-git by default?

[Sean Farley]

Arne Babenhauserheide <arne_bab at web.de> writes:

> Am Dienstag, 29. September 2015, 08:49:38 schrieb Kastner Masilko, Friedrich:
>> As for platform support (aka what features are supported for what system), Bitbucket's focus on Git instead of Mercurial naturally leads to such hick-ups as not being able to create pull-requests on bookmarks for a long time. Granted, they appear to have fixed it recently, but TBH I don't trust them on this anymore. Going forward, there will certainly be features on Bitbucket implemented for Git first, only much later - if at all - poorly implemented for Mercurial, because... market. I don't see them taking Mercurial's advanced features like largefiles or evolution as opportunity to get advantage over Github, unfortunately. Looks like if it is not in Git, they are not interested.
>
> When they hired Sean that gave me back some trust. Though I admit that
> I’m placing a lot of trust on very few people with that. And seeing
> other Atlassian solution not supporting Mercurial even after years of
> owning the largest Mercurial hosting platform is a pretty bad omen.

Aw, thanks :-) Unfortunately, the Stash team is a world away in Sydney
and historically that means it's difficult to share code. One way
forward, is to finish libchg so that we could wrap that instead of
directly accessing python. It would enable sharing the base layer
between SourceTree, Stash, and us.

>> IMHO, the Mercurial project should not focus on supporting Git even more, but on polishing features that Git does not offer, like the evolution concept or Facebook's extensions. Otherwise Mercurial will soon be just another footnote in Git's history. It sure seems like it is in Bitbucket's already.
>
> Sadly supporting git is nowadays required for many projects to
> contribute. Strategically it was a pretty clever move of git
> developers (though likely not a conscious decision) to focus mostly on
> project maintainers (remotes) and single developers (the index for
> history to be proud of), since these are the ones who decide in the
> end which system is used — regardless of the cost that incurs for most
> other members of the team. That’s especially true with free software
> projects where the one who starts the project mostly becomes the
> mainainer later one.

Agreed.

> However it would be cool to have the facebook extensions and evolution
> available at all times, maybe with some compatibility layer for
> servers which don’t support these.

That is, indeed, part of my plan.

> A short userstory: I recently wanted to use largefiles. I had to scrap
> that, because the project is on Bitbucket. Why can’t I just define
> largefiles to be served by my own server, and publish them there
> manually via FTP?  Maybe I can: If so, there should be pointers how to
> do that when trying to push to a non-largefiles capable server.

While largefile support is something we actively talk about, patching
the core extension to point to a different server is entirely doable (if
I understand correctly) without Bitbucket's need to change.