4 ms·

I heard that Facebook picked Mercurial because it was easier for them to make it work at their scale. On the other hand, the company I currently work for also

by rifung 12y ago

I heard that Facebook picked Mercurial because it was easier for them to make it work at their scale. On the other hand, the company I currently work for also uses Mercurial, but all the developers besides maybe the founder (I haven't asked) prefer Git. I don't know the specifics about why everyone feels that way but from what I gather it has to do with branching being easier.

jurip 12y ago
I've come to the conclusion that git got branches right. The idea of permanent metadata for branches is appealing, but repository-wide single namespace is bit of a PITA in some circumstance. Mercurial's bookmarks are the same as git's branches, but Bitbucket support is lacking. The other big thing git has is startup speed. Python is slow. Something like chg helps, but it's a workaround.
- ArneBab 12y ago
  I only see startup problems with hg when on the university cluster, where the filesystem is slow when accessing many files (metadata access). Startup speed for hg is on my machine below 100ms, less than the time most people need to type a single letter.
- rbehrends 12y ago
  I am not really happy with either Git's or Mercurial's solution. Git's branches introduce too much fragility in the system for end user consumption (because branches are responsible for both naming and keeping commits alive) and do not allow you to describe sets of commits (nor is there an alternative feature for that), Mercurial's branches are too permanent in that they cannot even be renamed (well, there's an extension for that, but that's not without issues). Mercurial bookmarks still do not allow you to label sets of commits, but at least aren't responsible for the liveness of a commit. In practice, I like both Fossil's and Bazaar's model better.
  - Skinney 12y ago
    What do you mean by a "set of commits". Why not just have topic branches? Branches isn't the only thing that keeps commits alive, you also got the reflog and tags. I have a hard time understanding why you would want to keep something alive that isn't reachable from the history.
    - rbehrends 12y ago
      Branches as sets of commits are useful for understanding history. I.e., which commits conceptually belong together and with a quick descriptor of what their purpose and/or who their primary author is (or whatever else your chosen policy for naming them is). That branches are not the only refs that keep commits alive is irrelevant, because the other refs by themselves are not sufficient; not every commit is reachable from a tag and reflog entries expire. Branches remain a necessary ingredient. Git needs this because it requires a named head for each commit because (1) it has a garbage collector and (2) it doesn't allow for multiple checkouts. In version control systems with multiple checkouts, a new branch will typically end up in a checkout of its own. Because there's no GC, it will not spontaneously disappear, and because each checkout keeps track of its own head, there's no need to name it. Git branches are an artifact of Git's odd architectural choices. But my bigger point is not about wanting to keep something alive that isn't part of the history, but that branches may not always accurately reflect what's part of the history (because Git allows you to alter them, and that's often even part of the normal workflow, e.g. deleting a temporary branch once you don't need it anymore). This usually does reflect human error, but, well, a major point of using a VCS is to protect against the results of human error. If you messed up your branches, then you can lose data either because (1) it eventually gets garbage-collected [1] or (2) it doesn't get pushed anymore and some day your computer or hard drive breaks. This is what I meant by Git introducing fragility. [1] Yes, once the grace period expires and it disappears from the reflog, but that only makes it less likely, not impossible, especially for stuff that sees only intermittent work.
      - Skinney 12y ago
        Well, you can set the expiration period for the reflog. If I remember correctly you can set it to "never". You can also disable alteration and removal of branches on a remote git repo. It's really all about knowing your tools. Then again, in my experience, if you manage to remove data or alter data which should not be removed or altered, and don't pick up on that before after the reflog expiration period, then you have bigger problems.

by rifung 12y ago

jurip 12y ago

I've come to the conclusion that git got branches right. The idea of permanent metadata for branches is appealing, but repository-wide single namespace is bit of a PITA in some circumstance. Mercurial's bookmarks are the same as git's branches, but Bitbucket support is lacking. The other big thing git has is startup speed. Python is slow. Something like chg helps, but it's a workaround.

ArneBab 12y ago
I only see startup problems with hg when on the university cluster, where the filesystem is slow when accessing many files (metadata access). Startup speed for hg is on my machine below 100ms, less than the time most people need to type a single letter.
rbehrends 12y ago
I am not really happy with either Git's or Mercurial's solution. Git's branches introduce too much fragility in the system for end user consumption (because branches are responsible for both naming and keeping commits alive) and do not allow you to describe sets of commits (nor is there an alternative feature for that), Mercurial's branches are too permanent in that they cannot even be renamed (well, there's an extension for that, but that's not without issues). Mercurial bookmarks still do not allow you to label sets of commits, but at least aren't responsible for the liveness of a commit. In practice, I like both Fossil's and Bazaar's model better.
- Skinney 12y ago
  What do you mean by a "set of commits". Why not just have topic branches? Branches isn't the only thing that keeps commits alive, you also got the reflog and tags. I have a hard time understanding why you would want to keep something alive that isn't reachable from the history.
  - rbehrends 12y ago
    Branches as sets of commits are useful for understanding history. I.e., which commits conceptually belong together and with a quick descriptor of what their purpose and/or who their primary author is (or whatever else your chosen policy for naming them is). That branches are not the only refs that keep commits alive is irrelevant, because the other refs by themselves are not sufficient; not every commit is reachable from a tag and reflog entries expire. Branches remain a necessary ingredient. Git needs this because it requires a named head for each commit because (1) it has a garbage collector and (2) it doesn't allow for multiple checkouts. In version control systems with multiple checkouts, a new branch will typically end up in a checkout of its own. Because there's no GC, it will not spontaneously disappear, and because each checkout keeps track of its own head, there's no need to name it. Git branches are an artifact of Git's odd architectural choices. But my bigger point is not about wanting to keep something alive that isn't part of the history, but that branches may not always accurately reflect what's part of the history (because Git allows you to alter them, and that's often even part of the normal workflow, e.g. deleting a temporary branch once you don't need it anymore). This usually does reflect human error, but, well, a major point of using a VCS is to protect against the results of human error. If you messed up your branches, then you can lose data either because (1) it eventually gets garbage-collected [1] or (2) it doesn't get pushed anymore and some day your computer or hard drive breaks. This is what I meant by Git introducing fragility. [1] Yes, once the grace period expires and it disappears from the reflog, but that only makes it less likely, not impossible, especially for stuff that sees only intermittent work.
    - Skinney 12y ago
      Well, you can set the expiration period for the reflog. If I remember correctly you can set it to "never". You can also disable alteration and removal of branches on a remote git repo. It's really all about knowing your tools. Then again, in my experience, if you manage to remove data or alter data which should not be removed or altered, and don't pick up on that before after the reflog expiration period, then you have bigger problems.