Craig Ozancin <c.ozan...@gmail.com> writes: > I did a little searching on this one and fond the following: > > https://openjdk.java.net/jeps/357 > > Their official reasoning is:
… kind of flaky … > Motivation > There are three primary reasons for migrating to Git: > > Size of version control system metadata > Available tooling > Available hosting > > Initial prototypes of converted repositories show a significant reduction > in the size of the version control metadata. For example, the .git > directory of the jdk/jdk repository is approximately 300 MB with Git and > the .hg directory is around 1.2 GB with Mercurial, depending on the > Mercurial version being used. The reduction in metadata preserves local > disk space and reduces clone times, since fewer bits have to go over the > wire. While the first parts are true but self-inflicted (renaming everything despite being asked not to, so I’m not sure whether it was intentional to give Git an edge), the latter is wrong — or would be, if they activated clone bundles on the server. As we’ve seen here, hg with clone bundles sends fewer bits over the wire. Not activating clone bundles seems very much intentional to me. And what I just realized when I cloned the firefox repo: I can simply download a clonebundle manually (with wget or similar), continuing the download if the connection goes down during download, and then clone directly from the local clone bundle. > Git also features shallow clones that only clone parts of the > history, resulting in even less metadata for those users who do not need > the entire history. This actually is a missing feature — I wish hg had it. We use it at work in the integration with Jenkins. > There are many more tools for interacting with Git than Mercurial: > > All text editors have Git integration, either natively or in the form of > plugins including Emacs (magit plugin), Vim (fugitive.git plugin), VS Code > (builtin), and Atom (builtin). Isn’t this the same with hg (since they allow plugins)? > Almost all integrated development environments (IDEs) also ship with Git > integration out-of-the-box, including IntelliJ (builtin), Eclipse > (builtin), NetBeans (builtin), and Visual Studio (builtin). Isn’t hg supported via plugins there? > There are multiple desktop clients available for interacting with Git > repositories locally. Same for hg? > Lastly, there are many options available for hosting Git repositories, > whether self-hosted or hosted as a service. This one sadly is true — more so with the loss of BitBucket. Atlassian buying BitBucket was really bad news :-( So the only valid points come down to: - renames are still expensive in hg - no shallow clones - less hosting options Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
_______________________________________________ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
