26 ms·

Ask HN: Google/FB engineers, Do you like Mercurial?

45 points by gitdude 11y ago

All the Google and Facebook engineers who are currently using Mercurial, I want to hear from them how they feel about Mercurial over Git. If they leave GooG or FB, will they still use Mercurial?

marvel_boy 11y ago
I did some work on Hg and I liked, but now EVERYBODY is using Git. Very similar systems by the way. I work on iOs apps.
mrweasel 11y ago
Why only Google and Facebook engineers? I use both Mercurial and Git, and honestly, they aren't that different. Unless you're doing something very specific I don't see why you would choose one over the other.
- pdw 11y ago
  I don't know about Google, but I believe Facebook keeps all of its code in one gigantic Mercurial repository.
  - jordigh 11y ago
    Not exactly "all", but certainly the mother load.
    - digitalsushi 11y ago
      Mother lode, the central, most valuable vein of buried gold.
      - jordigh 11y ago
        Oh, thanks! I'll let my original spelling stand as a testament to my ignorance. :-)
- thanksgiving 11y ago
  I've never used mercurial outside of TortoiseHg. In fact, the only time I've used mercurial is when I was attempting to build Firefox from source before I realized that they do a git mirror thing so you don't have to touch mercurial at all. I don't know much about mercurial. I use git because somebody said it is easier to rewrite history in git.
  - Fenume 11y ago
    Why would you rewrite history? Don't be ashamed.
    - allersj 11y ago
      For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.
      - jordigh 11y ago
        I do the same in hg. I do `hg amend` all the time to keep adding changes to my commit. At the end I may selectively undo some changes with `hg uncommit --interactive` or `hg uncommit --all` and redo the whole thing piecemeal with `hg commit --interactive` in order to slowly split up my work into several commits. Evolve makes it really easy to keep (and ignore!) a meta-history of all of my editions, with a clear lineage of which new commit replaced which prior commit. I may also rebase my work onto the latest head at the end (not to be confused with git HEAD). And all of this with a very nice interface. It's always --interactive, not sometimes --patch and sometimes --interactive.
        allersj 11y ago
        Thanks, that is useful to know. Mercurial was my first DCVS and I loved using it, but I only touched on the basic features. I stopped using it when I switched jobs and to become proficient with git. I'll have to give it another try with one of my side projects.
FraaJad 11y ago
the question about mercurial by "gitdude" is very umm.. leading.
- lifebeyondfife 11y ago
  You can be a fanboy about something and still want to understand why people prefer the alternative.
gcb0 11y ago
heavy mercurial user. all my open source projects are on it. first at Google code (rip) and now on bitbucket. though i have to use git at work daily. github to add insult... my finger memory is now on git. and that's where git "wins". the chance that you will be forced to use it and learn the awful laundry list of steps to properly use it (hint, if you ever type "pull" you are doing it wrong) you get your finger memory and then curse when you have to use the simple and more intuitive solutions. damn dumb fingers.
- lifebeyondfife 11y ago
  > hint, if you ever type "pull" you are doing it wrong Genuine question: what's wrong with executing 'git pull' on a branch you haven't changed locally?
  - leni536 11y ago
    It could be rebased upstream. While it's a really bad practice, it could happen.
    - lifebeyondfife 11y ago
      Ah ok, I think I understand the concern. So 'git fetch' and 'git merge' explicitly will stop an upstream rebase from making destructive changes to the history of your local branch(?) As you say it's bad practice and shouldn't happen. I use gitlab and GitHub where branches can be protected to only allow merges via their web interfaces.
      - leni536 11y ago
        I don't think git pull would ever destroy your history (AFAIK it's exactly the same as a fetch+merge), at worst you end up in a merge conflict, but it's easily revertable. However after a git fetch and a git log you can see beforehand if there is anything nasty going on.
      - sytse 11y ago
        GitLab CEO here, in GitLab you can protect branches to not be rebased at all (web or command line), see https://about.gitlab.com/2014/11/26/keeping-your-code-protected/ https://about.gitlab.com/2014/11/26/keeping-your-code-protec... I'm not aware that GitHub offers the same functionality.
jordigh 11y ago
Google is working on integrating Mercurial into their workflows, but hasn't quite achieved this goal yet. They are growing their hg team with hopes of replicating what Facebook has done, but they aren't there yet. Check out their contributions: http://selenic.com/hg/log?rev=google.com&revcount=80 http://selenic.com/hg/log?rev=google.com&revcount=80 Facebook is almost entirely hg by this point, though.
andreastt 11y ago
The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done. Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was Mozilla's recommended workflow. Queues are a novel way to organise your work in progress, but is quite different from what people are used to coming from svn or git. More recently bookmarks were added (also as an extension you have to opt-in to), which are reminiscent of git branches. They make it possible to have a HEAD-based workflow where you rebase frequently, much like you would with git, only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments. There are also many strange defaults in hg that you simply have to get used to, for example that `hg push` by default pushes everything. I have a hook in place on the remote end which prevents me from doing that. By far the most frustrating experience with hg is that you cannot expect the default installation to come with sensible defaults. The argument is that keeping "advanced" functionality out of core prevents new users from accidentally using it. An unintended consequence is that it sometimes makes it difficult for other people to help when you're stuck because more often than not their environment won't match yours. One frequently lauded aspect of hg is that the user interface is easier to understand. Whilst I appreciate difference in taste, my experience is the opposite. If you follow the HEAD-based bookmark-style workflow, I find many cognitive dissonances in how the bookmark feature interacts with other commands. At Mozilla we use hg for the canonical repositories and we have many Mozilla related extensions, but whereas I use hg every day now and it's a fine experience as long as I stay within the marked lines, I would return to git in a heartbeat if I had the chance.
- jordigh 11y ago
  Do you realise that "HEAD-based" doesn't mean anything? In git you are always at HEAD, by definition. It refers to the commit currently checked out, wherever it may be in history. The only way to not be at HEAD is to have a bare repo without a working directory. Mercurial calls this commit "the parent of the working directory" and uses the notation "." to refer to it. It's a very widespread common misconception that "HEAD" means "latest", probably because this is what it means in svn. And this brings up some very interesting usability research from Google: the vast majority of people who use any VCS don't really understand it: http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42942.pdf http://static.googleusercontent.com/media/research.google.co... I realise you are trying to say that you like to rebase and linearise your hg history. This is just `hg pull --rebase`, just like `git pull --rebase`. > only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments. I assume you want something like git where "log" by default starts from the currently checked out commit and hides the rest? You can have that, and if you don't like memorising the incantations to do that, you can save them as aliases in your ~/.hgrc
raldi 11y ago
Mercurial is almost unknown at Google.
heyts 11y ago
Honest question: could someone summarize why would one use mercurial vs git? Both seems really close in features. What would be a use case where one would outshine the other?
- jordigh 11y ago
  I promise I'll turn this FAQ you just posed into a wiki page... in the meantime, https://news.ycombinator.com/item?id=9467096 https://news.ycombinator.com/item?id=9467096

45 points by gitdude 11y ago

All the Google and Facebook engineers who are currently using Mercurial, I want to hear from them how they feel about Mercurial over Git. If they leave GooG or FB, will they still use Mercurial?

marvel_boy 11y ago

I did some work on Hg and I liked, but now EVERYBODY is using Git. Very similar systems by the way. I work on iOs apps.

mrweasel 11y ago

Why only Google and Facebook engineers? I use both Mercurial and Git, and honestly, they aren't that different. Unless you're doing something very specific I don't see why you would choose one over the other.

pdw 11y ago
I don't know about Google, but I believe Facebook keeps all of its code in one gigantic Mercurial repository.
- jordigh 11y ago
  Not exactly "all", but certainly the mother load.
  - digitalsushi 11y ago
    Mother lode, the central, most valuable vein of buried gold.
    - jordigh 11y ago
      Oh, thanks! I'll let my original spelling stand as a testament to my ignorance. :-)
thanksgiving 11y ago
I've never used mercurial outside of TortoiseHg. In fact, the only time I've used mercurial is when I was attempting to build Firefox from source before I realized that they do a git mirror thing so you don't have to touch mercurial at all. I don't know much about mercurial. I use git because somebody said it is easier to rewrite history in git.
- Fenume 11y ago
  Why would you rewrite history? Don't be ashamed.
  - allersj 11y ago
    For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.
    - jordigh 11y ago
      I do the same in hg. I do `hg amend` all the time to keep adding changes to my commit. At the end I may selectively undo some changes with `hg uncommit --interactive` or `hg uncommit --all` and redo the whole thing piecemeal with `hg commit --interactive` in order to slowly split up my work into several commits. Evolve makes it really easy to keep (and ignore!) a meta-history of all of my editions, with a clear lineage of which new commit replaced which prior commit. I may also rebase my work onto the latest head at the end (not to be confused with git HEAD). And all of this with a very nice interface. It's always --interactive, not sometimes --patch and sometimes --interactive.
      - allersj 11y ago
        Thanks, that is useful to know. Mercurial was my first DCVS and I loved using it, but I only touched on the basic features. I stopped using it when I switched jobs and to become proficient with git. I'll have to give it another try with one of my side projects.

FraaJad 11y ago

the question about mercurial by "gitdude" is very umm.. leading.

lifebeyondfife 11y ago
You can be a fanboy about something and still want to understand why people prefer the alternative.

gcb0 11y ago

heavy mercurial user. all my open source projects are on it. first at Google code (rip) and now on bitbucket. though i have to use git at work daily. github to add insult... my finger memory is now on git. and that's where git "wins". the chance that you will be forced to use it and learn the awful laundry list of steps to properly use it (hint, if you ever type "pull" you are doing it wrong) you get your finger memory and then curse when you have to use the simple and more intuitive solutions. damn dumb fingers.

lifebeyondfife 11y ago
> hint, if you ever type "pull" you are doing it wrong Genuine question: what's wrong with executing 'git pull' on a branch you haven't changed locally?
- leni536 11y ago
  It could be rebased upstream. While it's a really bad practice, it could happen.
  - lifebeyondfife 11y ago
    Ah ok, I think I understand the concern. So 'git fetch' and 'git merge' explicitly will stop an upstream rebase from making destructive changes to the history of your local branch(?) As you say it's bad practice and shouldn't happen. I use gitlab and GitHub where branches can be protected to only allow merges via their web interfaces.
    - leni536 11y ago
      I don't think git pull would ever destroy your history (AFAIK it's exactly the same as a fetch+merge), at worst you end up in a merge conflict, but it's easily revertable. However after a git fetch and a git log you can see beforehand if there is anything nasty going on.
    - sytse 11y ago
      GitLab CEO here, in GitLab you can protect branches to not be rebased at all (web or command line), see https://about.gitlab.com/2014/11/26/keeping-your-code-protected/ https://about.gitlab.com/2014/11/26/keeping-your-code-protec... I'm not aware that GitHub offers the same functionality.

jordigh 11y ago

Google is working on integrating Mercurial into their workflows, but hasn't quite achieved this goal yet. They are growing their hg team with hopes of replicating what Facebook has done, but they aren't there yet. Check out their contributions: http://selenic.com/hg/log?rev=google.com&revcount=80 http://selenic.com/hg/log?rev=google.com&revcount=80 Facebook is almost entirely hg by this point, though.

andreastt 11y ago

The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done. Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was Mozilla's recommended workflow. Queues are a novel way to organise your work in progress, but is quite different from what people are used to coming from svn or git. More recently bookmarks were added (also as an extension you have to opt-in to), which are reminiscent of git branches. They make it possible to have a HEAD-based workflow where you rebase frequently, much like you would with git, only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments. There are also many strange defaults in hg that you simply have to get used to, for example that `hg push` by default pushes everything. I have a hook in place on the remote end which prevents me from doing that. By far the most frustrating experience with hg is that you cannot expect the default installation to come with sensible defaults. The argument is that keeping "advanced" functionality out of core prevents new users from accidentally using it. An unintended consequence is that it sometimes makes it difficult for other people to help when you're stuck because more often than not their environment won't match yours. One frequently lauded aspect of hg is that the user interface is easier to understand. Whilst I appreciate difference in taste, my experience is the opposite. If you follow the HEAD-based bookmark-style workflow, I find many cognitive dissonances in how the bookmark feature interacts with other commands. At Mozilla we use hg for the canonical repositories and we have many Mozilla related extensions, but whereas I use hg every day now and it's a fine experience as long as I stay within the marked lines, I would return to git in a heartbeat if I had the chance.

jordigh 11y ago
Do you realise that "HEAD-based" doesn't mean anything? In git you are always at HEAD, by definition. It refers to the commit currently checked out, wherever it may be in history. The only way to not be at HEAD is to have a bare repo without a working directory. Mercurial calls this commit "the parent of the working directory" and uses the notation "." to refer to it. It's a very widespread common misconception that "HEAD" means "latest", probably because this is what it means in svn. And this brings up some very interesting usability research from Google: the vast majority of people who use any VCS don't really understand it: http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42942.pdf http://static.googleusercontent.com/media/research.google.co... I realise you are trying to say that you like to rebase and linearise your hg history. This is just `hg pull --rebase`, just like `git pull --rebase`. > only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments. I assume you want something like git where "log" by default starts from the currently checked out commit and hides the rest? You can have that, and if you don't like memorising the incantations to do that, you can save them as aliases in your ~/.hgrc

raldi 11y ago

Mercurial is almost unknown at Google.

heyts 11y ago

Honest question: could someone summarize why would one use mercurial vs git? Both seems really close in features. What would be a use case where one would outshine the other?

jordigh 11y ago
I promise I'll turn this FAQ you just posed into a wiki page... in the meantime, https://news.ycombinator.com/item?id=9467096 https://news.ycombinator.com/item?id=9467096