I understand and agree with most of what you point out here. But can you go into more details about what you mean when you say Mercurial scales better Git? I have an understanding of how Git suffers at a big scale. It also explains why companies like Google, Facebook, and till very recently Microsoft do not use Git. I know that Facebook uses Mercurial, but I believe they do hack it in some way to use it at such scale. The only reason why Microsoft is switching to Git is they can also afford to hack it, thus their GVFS project.
I have no idea where you read that Mercurial scales better than Git, since I sure didn't use the word "scale". However, if talking about the project and team growing, Mercurial makes it easier for growing teams to extend it to their needs.
It works better when you have team members with significantly varying environments due to the use of Python vs. relying on BASH scripts/binaries for hooks etc, and the extensibility and wide variety of already available great extensions does make it easier to tune how Mercurial works specifically for you.
Facebook does not "hack" it. They use it in it's intended way, using the extension APIs.
I used Scale as a broad term here. I used it because of your last paragraph about using git for small projects only, basically scale includes the number of developers.
Also, I believe that Git hooks can be written in any language you are comfortable with, especially Python.
Yes Facebook hacked Mercurial same way Microsoft is hacking Git with GVFS. It is literally almost the same story but two different systems. Microsoft has been actively contributing to Git along with Google Android project, same way Facebook contributed over 500 patches to Mercurial. GVFS is going to serve a skeleton of the repo similar to what remotefilelog does. This is done to hack both systems into thinking that their files are there locally.
From what I gathered, there is not much of a difference between both systems except for your opinion on them. In other words, Facebook only used Mercurial because "they" deemed it easier to change rather than do what Microsoft or Atom did with Git.
When you say Linus build Git to be used Linus (i.e a truly distributed use), same idea applies to Mercurial as a DVCS since Facebook cannot use it in a central manner without it breaking.
All opinions aside, both systems are good but Git would be a better option to learn and get used to given its bigger user base, this is including all its commands options inconsistencies not an opinion over how human readable they are.
I really don't think you understand the concept of "extensions". Try to google for "Git extensions" or "Git extensibility". Just try it, see what you find.
You also don't understand what I mean with Python hooks as you didn't bother to read anything about it. Mercurial can literally call Python functions with clear arguments, where these Python functions have access to the Python API Mercurial provides for them, which is a whole lot more powerful and cross-platform than Git hooks could ever be.
Also you seem to be using the word "hacking" in a rather uncommon way. Creating extensions using the APIs designed for it is not "hacking", it is creating extensions. Most of the great extensions FB made for Mercurial are also available as open source.
And no, you really do not understand the differences between Git and Mercurial. If you only think about "Git vs SVN" or "Mercurial vs SVN" yes, Git and Mercurial are similar. They ARE both DVCS systems based on similar ideas. However, if you think "Git vs Mercurial" there are many very clear differences.
Please do read the material provided before jumping into conclusions of your own. from FB's post: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project.".
"When you say Linus build Git to be used Linus (i.e a truly distributed use)", no, you are putting words in my mouth and interpreting them to mean something completely different. I did not mean he built it to be truly distributed, I meant he built it for HIMSELF and for his problems, using flags and designs HE was comfortable with, ignoring every other person on the planet, like he tends to do. You CAN use both Git and Mercurial in a centralized manner, just look at GitHub and BitBucket, that however has NOTHING to do with anything I said. The difference I was highlighting was that Mercurial has been built for other people to use, Git has been built for Linus to use, thus Mercurial ended up being a lot more friendly to other people.
No, something being more popular does not make it a better choice. No, you do not have to choose only one country and city to live in, one language to program in, one OS to use, one tool for any job, and most definitely you should not choose these facts based on perceived popularity.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand and agree with most of what you point out here. But can you go into more details about what you mean when you say Mercurial scales better Git? I have an understanding of how Git suffers at a big scale. It also explains why companies like Google, Facebook, and till very recently Microsoft do not use Git. I know that Facebook uses Mercurial, but I believe they do hack it in some way to use it at such scale. The only reason why Microsoft is switching to Git is they can also afford to hack it, thus their GVFS project.
I have no idea where you read that Mercurial scales better than Git, since I sure didn't use the word "scale". However, if talking about the project and team growing, Mercurial makes it easier for growing teams to extend it to their needs.
It works better when you have team members with significantly varying environments due to the use of Python vs. relying on BASH scripts/binaries for hooks etc, and the extensibility and wide variety of already available great extensions does make it easier to tune how Mercurial works specifically for you.
Facebook does not "hack" it. They use it in it's intended way, using the extension APIs.
code.facebook.com/posts/2186788149...
I used Scale as a broad term here. I used it because of your last paragraph about using git for small projects only, basically scale includes the number of developers.
Also, I believe that Git hooks can be written in any language you are comfortable with, especially Python.
Yes Facebook hacked Mercurial same way Microsoft is hacking Git with GVFS. It is literally almost the same story but two different systems. Microsoft has been actively contributing to Git along with Google Android project, same way Facebook contributed over 500 patches to Mercurial. GVFS is going to serve a skeleton of the repo similar to what remotefilelog does. This is done to hack both systems into thinking that their files are there locally.
From what I gathered, there is not much of a difference between both systems except for your opinion on them. In other words, Facebook only used Mercurial because "they" deemed it easier to change rather than do what Microsoft or Atom did with Git.
When you say Linus build Git to be used Linus (i.e a truly distributed use), same idea applies to Mercurial as a DVCS since Facebook cannot use it in a central manner without it breaking.
All opinions aside, both systems are good but Git would be a better option to learn and get used to given its bigger user base, this is including all its commands options inconsistencies not an opinion over how human readable they are.
I really don't think you understand the concept of "extensions". Try to google for "Git extensions" or "Git extensibility". Just try it, see what you find.
You also don't understand what I mean with Python hooks as you didn't bother to read anything about it. Mercurial can literally call Python functions with clear arguments, where these Python functions have access to the Python API Mercurial provides for them, which is a whole lot more powerful and cross-platform than Git hooks could ever be.
Also you seem to be using the word "hacking" in a rather uncommon way. Creating extensions using the APIs designed for it is not "hacking", it is creating extensions. Most of the great extensions FB made for Mercurial are also available as open source.
And no, you really do not understand the differences between Git and Mercurial. If you only think about "Git vs SVN" or "Mercurial vs SVN" yes, Git and Mercurial are similar. They ARE both DVCS systems based on similar ideas. However, if you think "Git vs Mercurial" there are many very clear differences.
Please do read the material provided before jumping into conclusions of your own. from FB's post: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project.".
"When you say Linus build Git to be used Linus (i.e a truly distributed use)", no, you are putting words in my mouth and interpreting them to mean something completely different. I did not mean he built it to be truly distributed, I meant he built it for HIMSELF and for his problems, using flags and designs HE was comfortable with, ignoring every other person on the planet, like he tends to do. You CAN use both Git and Mercurial in a centralized manner, just look at GitHub and BitBucket, that however has NOTHING to do with anything I said. The difference I was highlighting was that Mercurial has been built for other people to use, Git has been built for Linus to use, thus Mercurial ended up being a lot more friendly to other people.
Also your last point is such a clear logical fallacy it's laughable. yourlogicalfallacyis.com/bandwagon
No, something being more popular does not make it a better choice. No, you do not have to choose only one country and city to live in, one language to program in, one OS to use, one tool for any job, and most definitely you should not choose these facts based on perceived popularity.