Why rebase mercurial

Sourcetree is an easy-to-use app that connects to many of the popular source code hosting tools out there like Bitbucket, Kiln and for Git users GitHub. With Mercurial, Windows support is a first-class feature.

The Mercurial crew cares about Windows users and is very concerned with being completely cross-platform. You can build core Mercurial from source on a Windows machine and use it without having to rely on prepackaged binaries if you like. Git, on the other hand, does not provide support for Windows in its core code. There is a project called msysgit that adds compatibility for Windows. Mercurial knows that everyone is going to have different needs, so it provides several ways to extend its functionality without changing the core code.

The first method of extending Mercurial is writing shell scripts that call its command line interface. Once that script is on your path you can simply run hgpastediff to paste the code to dpaste, and the location of the paste will be printed for you.

Another way to extend Mercurial is to use aliases. Aliases let you define new Mercurial commands that run other commands, possibly with arguments. The 1. When that happens, you can write your own Mercurial extension using the extension API. Extensions are written in Python like Mercurial itself , which is a very common and elegant programming language.

There are several places to turn to for Mercurial support and training. At the same time as rebasing, it is a common practice to combine your commits into one. Again, this is more about keeping the history of your repository nice and clean. If you made 20 commits to implement a single feature, perhaps with a few of them going in directions that you later backtracked out of, do you really want all those to be pushed up into the master repository? Again, at some point in the future, someone will be trawling back through history trying to find where something went wrong, and it is a waste of their time to look at a revision that perhaps contains a silly mistake might not even build , when your work could be combined into one revision.

Having your feature contained in a single commit also makes life simpler for the code reviewer, since they can just look at the diff for that one revision although your tools ought to be able to show you a combined diff for a range of revisions — I noticed that github does this very elegantly with pull requests that contain multiple revisions. But that shouldn't be the point of combining commits.

You do it to save time for whoever in the future needs to look back at the history of the project. So if rebase makes our history simpler, why would some people not want to use it.

There are a few dangers associated with rebasing and combining commits. The biggest danger with rebase is rebasing already published revisions. This is most likely to happen if you accidentally rebase the wrong way round rebasing changes you pulled in from elsewhere onto your own work , something I imagine would be quite easy to do by mistake for a beginner with DVCS.

Or maybe you forgot or unintentionally already pushed the revisions you are about to rebase to a public repository. Doing this means that the revisions you rebased, rather than disappearing, will keep coming back again, and end up getting merged back in alongside the rebased versions of the same change. It can be very hard with a DVCS to get rid of revisions you no longer care about once they have been published.

In Mercurial 2. This means that commands like rebase can now refuse to work on published revisions, making it a much safer command to use.

It will be interesting to see how well this works in practice, and if it does work, maybe Mercurial will allow rebase and other history changing extensions, to be enabled by default. Having said that, since unlike git , Mercurial by default pushes and pulls all heads, you might find you end up sharing a work in progress branch earlier than you intended.

In this example I am using --force to draft commits already pushed to my fork. Doing this is not best practices on a main repository. As with all examples, this one is rather straight forward but rebasing can become a complicated affair if you need to fix merges and conflicts during the rebase. For more detailed rebasing information, see the Mercurial Rebase page which has more detailed instructions for various scenarios.