3 ms·

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

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?

GrumpyYoungMan 10y ago
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?
- dmitry-k 10y ago
  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 https://news.ycombinator.com/item?id=9497821
alkonaut 10y ago
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.
- mi100hael 10y ago
  > 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.
  - Stratoscope 10y ago
    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.)
    - flukus 10y ago
      For every legitimate use of binaries in source control there are dozens of idiots checking in build artifacts.
      - alkonaut 10y ago
        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.
  - alkonaut 10y ago
    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!

GrumpyYoungMan 10y ago

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?

dmitry-k 10y ago
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 https://news.ycombinator.com/item?id=9497821

alkonaut 10y ago

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.

mi100hael 10y ago
> 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.
- Stratoscope 10y ago
  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.)
  - flukus 10y ago
    For every legitimate use of binaries in source control there are dozens of idiots checking in build artifacts.
    - alkonaut 10y ago
      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.
- alkonaut 10y ago
  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!