Git vs mercurial windows series#

Mercurial tries to be helpful by anticipating some of the more common aliases for commands and just making them work. It favors clarity over “cleverness”, which makes for an easier-to-use tool. It’s easy to find what you’re looking for - using hg help, so you can spend less time looking at docs and get back to coding. Mercurial’s simple approach leads to documentation which is sleek and concise. Git’s documentation must detail all the interactions between options, which makes it more verbose and difficult to skim. This makes for less typing, but requires you to remember all of the various options and how they interact with each other. Each command has many options that can change its behavior. Git’s CLI is designed to be extremely flexible. It follows the UNIX philosophy: “each command should do one thing and do it well.” Mercurial’s CLI is full-featured, stable, and elegant. The command line interface is the first thing many programmers will see when using a new version control system.

Git vs mercurial windows series#

There are many reasons (and opinions) why one would choose Git or Hg, and the next two blog posts in this series aim to explain some of these Whys. There are two major distributed version control systems in widespread use today: Mercurial (Hg) and Git. In our previous posts, we talked about the history of version control and why it’s a good thing, as well as why distributed version control systems are better than centralized systems.

Check out Steve’s projects to see some of the cool things he has worked on around Distributed Version Control, or jump over to his Bitbucket account and fork one of his many projects. This is a guest blog post by Steve Losh focusing on the primary reasons a team may choose Mercurial as their (distributed) version control system.