Most of these extensions will also permanently back up any changesets that they destroy into a bundle. Keeping this functionality out of core prevents new users from accidentally using it until they’re ready. Including destructive commands in core means new users are more likely to shoot themselves in the foot by running commands with implications they don’t fully understand.įor the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Yes, you can find changesets you’ve destroyed through git rebase –interactive using git reflog, but if it has been more than a month since you made the change, those changesets will be lost (Git will “garbage collect” these changesets after a month). Commands like git rebase –interactive let you rewrite history, possibly discarding data along the way. Git, on the other hand, lets you play fast and loose with your project’s history. This command will “undo” the last pull or commit, but will never touch anything further back. Mercurial’s philosophy is that “history is permanent and sacred.” Core Mercurial includes only one single command that can alter history: hg rollback.
Worse, it simply isn’t necessary, as Mercurial’s Subversion-user-friendly but still powerful and elegant interface proves. While you can work around this by retraining your fingers to type the new commands, it’s yet one more roadblock to switching systems. Subversion (SVN)Īs you can see, Git makes less of an effort to organize its CLI in a way that Subverison users will be used to. Mercurial/Git commands that are the same as their Subversion equivalents are bold. Here’s a comparison of some of the most common commands. Mercurial’s CLI is also quite similar to Subversion’s, which can help ease the transition between the two tools. You can create your own git move alias if you like, but that’s yet another step to try to make Git’s CLI pleasant to use while Mercurial’s is pleasant by default. For example, the hg rename command can also be run with hg move or hg mv. 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.
#Bitbucket tortoisehg 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.
0 kommentar(er)
