5 ms·

We would seriously consider GitLab if they supported Mercurial. I am so annoyed with atlassian (another company that perhaps could pay attention more to develop

by agentgt 10y ago

We would seriously consider GitLab if they supported Mercurial. I am so annoyed with atlassian (another company that perhaps could pay attention more to developers). I like git for OSS but we love hg for our internal projects.

david-given 10y ago
It's a bit crufty, but you might want to look at hg-git: http://hg-git.github.io/ 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.
deleted 10y ago
[deleted]
marcinkuzminski 10y ago
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.
daigoba66 10y ago
> 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?
- ergo14 10y ago
  Big file support - this is important for asset management in game dev for example. First class windows support.
  - jobvandervoort 10y ago
    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.
    - marcinkuzminski 10y ago
      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.
      - sytse 10y ago
        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.
    - stonith 10y ago
      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).
  - 10y ago
jobvandervoort 10y ago
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.

by agentgt 10y ago

david-given 10y ago

It's a bit crufty, but you might want to look at hg-git: http://hg-git.github.io/ 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.

deleted 10y ago

[deleted]

marcinkuzminski 10y ago

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.

daigoba66 10y ago

> 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?

ergo14 10y ago
Big file support - this is important for asset management in game dev for example. First class windows support.
- jobvandervoort 10y ago
  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.
  - marcinkuzminski 10y ago
    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.
    - sytse 10y ago
      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.
  - stonith 10y ago
    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).
- 10y ago

jobvandervoort 10y ago

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.