Differences between Git and Mercurial

Question

What are the main differences, advantages and limitations of these two distributed version control systems?

If anyone has practical experience in both (for example I only know the Mercurial more deeply, and I am in doubt whether or not I should delve into Git), I would also like to know if there is any scenario or use case where one has advantages over the other, or if they are essentially equivalent.

Answer 1

Summary:

Git

Git is the rising star of version controls, it was developed by the creator of the linux kernel and has recently been widely used by the astounding developer community, Git offers a different version control, the Distributed Version Control, or simply, distributed version control, with this form of control there is no central server as in SVN for example, which uses centralized version, the community says that Git is the fastest version control on the market, among some who use Git we can mention the Linux Kernel, Wine, Fedora, among others, Github has established itself as a large version control based on Git, providing a beautiful front end for large projects such as Rails and Prototype, however, Git is not very easy to learn, so it’s not much recommended for beginners in the version control world, clients can be found here.

MERCURIAL

Mercurial is another distributed version control just like Git, it was developed for large projects, far beyond the simple projects of independent designers and developers, obviously that doesn’t mean that small teams can’t use itlo, Mercurial is extremely fast and the creators focused on performance as the most important resource. In addition to being very fast and scalable, Mercurial is simpler than Git, there are not as many functions to learn and the functions are similar to other CVS’s, besides it comes equipped with a web interface and have excellent documentation. A list of clients for Mercurial can be found here and for an excellent tutorial in English, just click here. As an additional, I leave a link of an article talking a little about the performance of the version controls mentioned above, access the following link.

Source : which-the-best-control-of-versation-subversiongitmercurial

Although it is a comparative, between Subversion, Git and Mercurial I believe it can help the author of the question.

Complexity

The complexity of the tool has a direct impact on the productivity of the developers and is the decisive factor for the learning and correct operation of the tool. The criteria used to measure it were the number of commands and the number of lines of the help texts. Although they are not perfect, they are sufficient to indicate the complexity of the tool, as well as being impartial and easy to measure. Other dimensions of complexity of the tools will be addressed in later analyses. The details of the criteria and the comparison premises are presented below:

1. Number of commands. All tools have dozens commands and knowing them is a challenge for any user.

Premise: The smaller the number of commands, the easier it is to know them.

Counterargument: There could be a command with only dozens of options and parameters, and that wouldn’t make it simpler. However, the help text of this command would be longer. Therefore, only the number of commands is not enough, but if combined with the analysis of the number of help lines of the commands, becomes relevant again.

2. Help text line numbers. All tools help texts for your commands in order to present the operation of the command and the available options. Premises:

to. The format and quality of the help texts of the different tools being analyzed are equivalent.

b. Help texts contain only the minimum amount of content needed to adequately describe commands.

c. More complex commands need longer text to be described. Therefore, the smaller the number of lines of help text needed to explain a command, the simpler it is.

Number of Commands

Subversion has 68 different commands, grouped into categories: svn for versioning tasks, svnadmin for manipulating and maintaining repositories, svnlook for examining the repository in hook scripts, etc.: Subversion: 68 different commands (Some repeat. For example, help) svn: 36 commands add, Blame, cat, changelist, checkout, Cleanup, commit, copy, delete, diff, export, help, import, info, list, lock, log, merge, mergeinfo, mkdir, move, patch, propdel, propedit, propget, proplist, propset, relocate, resolve, resolved, revert, status, switch, Unlock, update, upgrade svnadmin: 20 commands crashtest, create, deltify, dump, help, hotcopy, list-dblogs, list-unused-dblogs, load, lslocks, lstxns, pack, recover, rmlocks, rmtxns, setlog, setrevprop, setuuid, upgrade, verify svnlook: 17 commands Author, cat, changed, date, diff, dirs-changed, filesize, help, history, info, lock, log, propget, proplist, Tree, uuid, Youngest svnrdump: 3 commands dump, load, help svndumpfilter: 3 commands exclude, include, help svnsync: 5 commands initialize, Synchronize, copy-revprops, info, help

The Mercurial has 55 commands in total (with fetch and rebase enabled), which can increase according to the number of extensions enabled. Eighteen of these commands are considered basic, presented when executing the Hg command without any subcommands or additional parameter. There is no further subdivision of the commands into an administrative class or for scripts like Subversion, although there are clearly directed commands for exactly these purposes, such as Verify and identifyfor example.

Mercurial: 55 commands

Basic (18 commands) - listed by the Hg command: add, annotate, clone, commit, diff, export, Forget, init, log, merge, Phase, pull, push, remove, serve, status, Summary, update Advanced (37 commands) - additional commands listed by the Hg help command: addremove, Archive, backout, bisect, bookmarks, branch, branches, Bundle, cat, copy, fetch, graft, grep, heads, help, identify, import, incoming, locate, manifest, Outgoing, parents, paths, rebase, Recover, Rename, resolve, revert, rollback, root, showconfig, tag, tags, tip, unbundle, Verify, version Git has 144 commands in total. Twenty of these are the most commonly used according to the list provided by the git command without additional parameters or keys. The complete list of commands is provided by the git help --all command:

git: 144 commands

Common (21 commands) - listed by the git command: add, bisect, branch, checkout, clone, commit, diff, fetch, grep, init, log, merge, mv, pull, push, rebase, reset, rm, show, status, tag Advanced (123 commands) - additional commands listed by the git help command --all: add-Interactive, am, annotate, apply, Archive, bisect-helper, Blame, Bundle, cat-file, check-attr, check-ref-format, checkout-index, Cherry, Cherry-pick, clean, commit-Tree, config, Count-Objects, Credential-cache, Credential-cache-daemon, Credential-store, daemon, describe, diff-files, diff-index, diff-Tree, difftool, difftool-helper, fast-export, fast-import, fetch-pack, filter-branch, fmt-merge-msg, for-each-ref, format-patch, fsck, fsck-Objects, gc, get-tar-commit-id, hash-Object, help, http-backend, http-fetch, http-push, imap-send, index-pack, init-db, instaweb, Lost-found, ls-files, ls-remote, ls-Tree, mailinfo, mailsplit, merge-base, merge-file, merge-index, merge-Octopus, merge-one-file, merge-Ours, merge-recursive, merge-resolve, merge-subtree merge, -Tree, mergetool, mktag, mktree, name-rev, Notes, pack-Objects, pack-Redundant, pack-refs, patch-id, Peek-remote, Prune, Prune-packed, quiltimport, read-Tree, receive-pack, reflog, relink, remote, remote-ext, remote-fd, remote-ftp, remote-ftps, remote-http, remote-https, remote-testgit, repack, replace, Repo-config, request-pull, rerere, rev-list, rev-parse, revert, send-pack, sh-i18n-envsubst, shell, shortlog, show-branch, show-index, show-ref, Stage, stash, stripspace, submodule, Symbolic-ref, tar-Tree, unpack-file, unpack-Objects, update-index, update-ref, update-refserver-info, upload-Archive, upload-pack, var, Verify-pack, Verify-tag, web-Browse, whatchanged, write-Tree Git has a greater amount of commands than Subversion and Mercurial combined! This is not due to a greater number of features. It is only an indication of failure in the conceptual integrity of the project, which can be explained in part for historical reasons of development: Git was originally designed as a low-level (abstraction) version control engine from which others could write applications... However, the Git core project has become a full version control system that is used directly.

It would be better if the low-level commands had been moved to some library, where they would be visible only to Git developers, away from the tool’s end users.

Observing

This would provide a qualitative analysis of certain Git conceptual integrity problems. However, in order not to mix with the quantitative analyses being presented, this aspect will be presented at another time. Not only does the number of commands influence learning and operation, but also how they are organized. Subversion does not have the least number of commands, but organizes them into categories that make the user’s life much easier. A developer, for example, would only need svn subcommands for version control operations, an administrator of svnadmin subcommands, and so on. In DVCS, the repository is local and therefore all types of operation are the responsibility of the developer himself. Since the name of the command does not always make clear its purpose and the division of commands only into basic and advanced does not add much information either, Mercurial and Git should use more categories to classify the commands. Better: Mercurial (fewer commands) and Subversion (better organization of commands) Line Numbers per Command The counting of the lines of the help text will be done through the following commands: $ svn help | wc -l $ Hg help | wc -l $ git help |

2. Because some Git commands run several different features, some help texts will be added to keep the comparison balanced. For example, the help text of the git checkout command will be compared to the grouping of the help texts of the Mercurial update, branch and revert commands: $ (Hg help update && Hg help branch && Hg help revert) | wc -l

3. Some Subversion, Mercurial, and Git commands have the same name but perform totally or partially different operations, such as the revert command and revert command. Despite this, they will be treated as equivalent.

4. Commands such as push and pull do not exist in Subversion. In these cases, the counted number of rows is zero.

5. The number of lines in Git’s help text varies depending on the terminal width. The analysis presented used a width of 80 columns for the measurements. The following table shows the data collected from the execution of scriptcomparativo_help_svn_hg_git.py:

the table can be seen in this link.

The graphical representation of the results is shown below:

Git has longer text in all cases, which indicates its commands are harder to explain.

Subversion had a larger total of text lines than Mercurial, even with fewer commands being parsed. Responsible was the command svn merge, which is admittedly complex in Subversion and whose help text alone accounts for more than a third of the total. This reinforces the premise that the more complex the command, the greater the number of corresponding help text lines.

The Mecurial did better both in the overall picture and in all commands equivalent to Subversion. By the logic used, Mercurial commands are simpler than Git commands and even than Subversion commands.

Better: Mercurial

Completion

The numbers collected indicate that Git is more complex than Subversion and Mercurial, which was expected as reported in several analyses available on the internet (1, 2, 3, 4).

Source: Link

Answer 2

By design git is faster on backward Linux operating systems windows support is limited and in short it is more flexible and powerful. On the other hand Mercurial is simpler and easier to learn, so the learning curve is shorter.

Git has incredible documentation, all online and in various languages, and has improved in terms of simplicity. But it is said that the documentation of Hercules is also great.

I recommend git for having a larger community, for being faster at operations that need to communicate with the network, for having more options for code hosting services (such as bitbucket, github, and Gitorious), for being more complete (has command options available but this increases somewhat in complexity).

You can learn more about the differences between them by here and here.

Answer 3

Git has many good services and the best solutions for continuous integration, loses on the interface part, ok has Sourcetree and Magit, but nothing compared to Tortoisehg, HG’s performance is much better than GIT. Merge conflicts are much easier to resolve in HG than in GIT. For beginners in versioning HG is simpler, but for advanced things like working with History better than GIT.

Are not equivalent