It would severely hurt our velocity if we'd decided to support Mercurial, whilst the benefit is only for a small group of potential users. We're not planning to support hg.

Would a migration tool or something similar help?

A git migration tool would be terrific: I'm on a svn project with a 20Gb history, 3Gb working copy, with TONS of versioned binary assets. The migration story to git is a nightmare with lots of different tools and utilities that reportedly do some part of the migration, but don't play well together.

I'd like to see a simple conversion tool that lets me configure everything (branch filters, user conversion, wildcards for what assets must go to LFS) that lets me convert a repo in TFS/SVN/HG into git with LFS.

The key here is integrated LFS. Without it, git is a complete no go for any shops that does lots of large versioned binaries. Git+LFS still seems like black magic to me, so it would be nice to see someone make a friendlier front for it.

> Without it, git is a complete no go for any shops that does lots of large versioned binaries.

Git is source control. It's for versioning source, not binaries. Built dependencies or artifacts or whatever else should be stored somewhere else like FTP.

For some of us, binaries are source. For example, anyone developing in Unity or Unreal Engine has large binary files that represent the game levels, blueprints, and other assets. These aren't generated files, logically they are source code that should be versioned along with the textual source code.

(Tip for Unity users: The very first thing to do when you start a project is to go into the project settings and change it to Text Assets. That way the scene files and such will be text instead of binary. It's still a fairly opaque YAML format, but at least they will be more diffable.)

For every legitimate use of binaries in source control there are dozens of idiots checking in build artifacts.

Build artifacts aren't necessary to bring over to git in a conversion from hg/svn. I archive installers and other artifacts in svn, but if I moved to git I'd just archive those somewhere else. The binaries that are actually part of the build (a few binary dependencies, lots of graphics, test in/out data etc) must be next to the source however because those are needed to reproduce a build.

That's why I (and many others) need Git+LFS - because I need a lot of versioned artifacts such as images and binary application documents. One example is test inputs and outputs if you have an app that produces and consumes binary data. Every revision of the source tree needs the right revision of the corresponding binaries.

You are right that this is solvable with ftp, with one folder per revision and some scripting to manage committing source changes to git and binary changes to ftp but that is pretty much what git+LFS is!

> that is pretty much what git+LFS is!

Right, which is why I replied in the first place. The parent seemed to think LFS was black magic and didn't want to adopt git without it. In reality LFS is just another versioned file storage scheme similar to a Nexus repo or Linux distro package repo. Any FTP server and a script to push artifacts at the end of a build would get the job done.

I meant it seems like black magic to get it set up properly. Especially on windows.

> Any FTP server and a script to push artifacts at the end of a build

The binaries in this case aren't produced by the build, they are test input data, test output data, graphics files etc., and without them a developers' build or tests will likely fail.

So any time a developer updates his working copy (git pull, svn update, whatever) the the binaries need to be in sync, preferably automatically, since otherwise the source code itself is useless. It seems to me that LFS was designed to allow the user to not download all the binaries, but instead leave the small pointer files. That might be handy, but in my scenario I need ALL the binaries in place and up to date all the time. Basically I need to alias any syncing to also do the git lfs fetch.

Any time the user commits changes (svn commit, git push etc) the binaries must also be pushed.

I'd be very happy to adopt git but for acceptance within the organization it needs that seamless integration of binary versioning without extra steps, and also file locking.

> I meant it seems like black magic to get it set up properly. Especially on windows.

Just wanted to add that Christian Couder that is part-time on our team is working to integrate LFS into git itself to make it easier to use.

That's very good news.

I'm not the original poster but some of us prefer Mercurial's workflow to git's, so a migration tool, while nice to have as an option, isn't what would help win customers like us. (I do like the direction that GitLab is taking, though.)

As an aside to the general HN readership, are there any good Mercurial hosts other than BitBucket?

RhodeCode is self-hosted, but you can run it in Azure/Amazon cloud. For large companies, that setup might prove even more stable than relying on someone else's cloud [1]

[1] GitHub's down? https://news.ycombinator.com/item?id=9497821

Marcin from RhodeCode here. You should consider checking out RhodeCode, it's openSource and supports Mercurial, along with Git and Subversion. It's built explicitly for internal usage behind the firewall.

It's a bit crufty, but you might want to look at hg-git: http://hg-git.github.io/

It allows you to use hg as a git client. It supports git branches (mapped to hg bookmarks), tags, etc and is mostly pretty seamless, with a few rough edges where the semantics don't quite match up --- e.g., hg supports moving tags, which git doesn't like doing.

I use it with github, and have done some pretty complex stuff with it, and nearly everything has Just Worked. The biggest problem is with the bookmark-to-branch mapping, so I tend to create/delete branches via the github web UI, then pull the repository to update the client, but I'm totally willing to admit that I've never really bothered to learn much about how that works so I could just not be driving it properly.

> we love hg for our internal projects.

We too use hg for our code. But I wouldn't say we "love" it - it works and we haven't found a compelling reason to switch.

So I'm curious, what about hg makes it great for some projects?

Big file support - this is important for asset management in game dev for example.

First class windows support.

Big file support that works transparently without ever giving the feeling that it's tacked on. Real file locking support for those binaries is also critical.

Have you tried using LFS or Git Annex for big files instead?

We've also built File Locking in specific to make it working with big assets a bit safer.

Windows support in Git can definitely be improved, though luckily there are many great Git clients available nowadays.

I think git LFS is having same issues as Mercurial Large Files had in the beginning. It's going to get there, but it takes time. We're considering that Mercurial LargeFiles support is much more mature.

In regards to Git vs HG. We see that most of the users take advantage of plugin system that Mercurial has, eg Facebook with their plugins for handling huge monorepos.

It also adds some advanced workflows, eg doing a code-review using phases and secret commits makes it much more pleasant to work compared to Git.

FileLocking is quite easy with Mercurial actually. We're working on some other approach on this actually and want to work on a better system that emulates what SVN/Perforce have and bring it to Git and Mercurial with RhodeCode as the tool to have at least basic file permissions.

Just wanted to add that Christian Couder that is part-time on our team is working to integrate LFS into git itself to make it easier to use.

Not OP, but I tried Annex with Unreal 4 and the symlinks caused problems with the editor. Obviously that's a UE4 issue rather than an Annex issue, but it meant LFS was the only reasonable option at the time when I tested (~12 months ago).