3 ms·

Technically I think Mercurial would be better for engineering wise in the long term. Mercurial has a single implementation (Git has 5), and they greatly discou

by kyrra 7y ago

Technically I think Mercurial would be better for engineering wise in the long term. Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation. Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).

WorldMaker 7y ago
> Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). The file system changes were extremely low level and likely couldn't have been handled with extension hooks in Hg either (some of it, from what I read of it, would be more like the equivalent of changing the Python standard library, specifically the OS and file-system-specific bits, underneath Hg than changes to Hg or its extensions). It was also a relatively short-lived fork as it did merge upstream. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). Since Microsoft has taken an active role in git development, and especially since the Windows team itself switched to git, the official Git for Windows install and support for that install has been really good. While git will likely always need some bits of Linux abstraction because how much of it's "high level" is written in Bash shell scripts and random bits of awk / sed / perl, it certainly seems that the low level stuff is less reliant on Linux abstraction than ever and is increasingly cross-platform-intended C. (Just about every major performance boost across the board has usually included rewriting to directly cross-platform code.) Python will always generally be "simpler/stabler cross-platform" for Mercurial, but git has done a remarkable job at catching up on the cross-platform space over the years.
inspector-g 7y ago
> Mercurial has better hooks in place We use the hell out of this at my company. Mercurial's hooks have made a wide variety of automatic tasks much easier to systematize across all our repos for any repo-related action that any dev makes. Here's one of our use cases. Mercurial, at least in the early days, had much better support (IMHO) for large/binary files than git (perhaps git is on-par now, not sure). We needed some of the projects in our repos to be fully compilable against any binaries/assets at any point in time in the repo's complete history. We implemented this with a combination of Mercurial's first-party "largefiles" extension, high compression of our binaries/assets (via 7z), and a variety of scripts/hooks to (de)compress the relevant files whenever `hg commit`, `hg up`, `hg revert`, etc. is performed. Sure, you greatly increase the size of a repo on whatever machines are serving it, but storage is cheap these days so who cares. Devs also have to deal with more disk space being used, but a) storage is cheap and b) it is trivial to clear old binaries/assets from their disk on an automated schedule. Whenever they update/revert to another revision/branch the binaries/assets download automatically anyway.
cryptonector 7y ago
> Technically I think Mercurial would be better for engineering wise in the long term. I don't see why. I've seen companies switch from Mercurial to Git even though many employees loved Mercurial -- the driver was the fact the new employees were much more likely to prefer Git or not even know what Mercurial is. Mindshare matters. > Mercurial has a single implementation (Git has 5), Eh? I very much like that there are multiple Git implementations. Besides choice, this means there are more people who really understand its guts and can support it and its implementations. > and they greatly discourage anyone from implementing a second. That's not a good thing. > This gives them a single source of truth for the implementation. That gives them too much power to make changes the users might not like. > Mercurial has better hooks in place. Sounds like one of the ways in which Git implementations might differentiate from each other. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). MSFT is doing amazing work on Git on Windows, making it scale in ways no other distributed VCS is likely to any time soon without adopting similar ideas. If you want Windows support, then Git is going to rock your boat more than Mercurial soon if not already.

by kyrra 7y ago

WorldMaker 7y ago

> Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). The file system changes were extremely low level and likely couldn't have been handled with extension hooks in Hg either (some of it, from what I read of it, would be more like the equivalent of changing the Python standard library, specifically the OS and file-system-specific bits, underneath Hg than changes to Hg or its extensions). It was also a relatively short-lived fork as it did merge upstream. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). Since Microsoft has taken an active role in git development, and especially since the Windows team itself switched to git, the official Git for Windows install and support for that install has been really good. While git will likely always need some bits of Linux abstraction because how much of it's "high level" is written in Bash shell scripts and random bits of awk / sed / perl, it certainly seems that the low level stuff is less reliant on Linux abstraction than ever and is increasingly cross-platform-intended C. (Just about every major performance boost across the board has usually included rewriting to directly cross-platform code.) Python will always generally be "simpler/stabler cross-platform" for Mercurial, but git has done a remarkable job at catching up on the cross-platform space over the years.

inspector-g 7y ago

> Mercurial has better hooks in place We use the hell out of this at my company. Mercurial's hooks have made a wide variety of automatic tasks much easier to systematize across all our repos for any repo-related action that any dev makes. Here's one of our use cases. Mercurial, at least in the early days, had much better support (IMHO) for large/binary files than git (perhaps git is on-par now, not sure). We needed some of the projects in our repos to be fully compilable against any binaries/assets at any point in time in the repo's complete history. We implemented this with a combination of Mercurial's first-party "largefiles" extension, high compression of our binaries/assets (via 7z), and a variety of scripts/hooks to (de)compress the relevant files whenever `hg commit`, `hg up`, `hg revert`, etc. is performed. Sure, you greatly increase the size of a repo on whatever machines are serving it, but storage is cheap these days so who cares. Devs also have to deal with more disk space being used, but a) storage is cheap and b) it is trivial to clear old binaries/assets from their disk on an automated schedule. Whenever they update/revert to another revision/branch the binaries/assets download automatically anyway.

cryptonector 7y ago

> Technically I think Mercurial would be better for engineering wise in the long term. I don't see why. I've seen companies switch from Mercurial to Git even though many employees loved Mercurial -- the driver was the fact the new employees were much more likely to prefer Git or not even know what Mercurial is. Mindshare matters. > Mercurial has a single implementation (Git has 5), Eh? I very much like that there are multiple Git implementations. Besides choice, this means there are more people who really understand its guts and can support it and its implementations. > and they greatly discourage anyone from implementing a second. That's not a good thing. > This gives them a single source of truth for the implementation. That gives them too much power to make changes the users might not like. > Mercurial has better hooks in place. Sounds like one of the ways in which Git implementations might differentiate from each other. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). MSFT is doing amazing work on Git on Windows, making it scale in ways no other distributed VCS is likely to any time soon without adopting similar ideas. If you want Windows support, then Git is going to rock your boat more than Mercurial soon if not already.