Wandering Thoughts archives

Rebasing changes can be common when working with version control systems

There is a general distinct dislike of Git's support for rebasing (cf). I have some views on this in general (eg), but I feel that one overlooked thing may be that it's not uncommon for people in certain situations to "rebase" changes when working with VCSes, whether or not they use Git and 'git rebase'. If you look at rebasing changes as a conceptual operation instead of a Git one, there are a number of ways that it happens and often VCSes that are otherwise resistant to the idea of rebasing support some versions of it.

To start with, let's take Git. If you maintain uncommitted changes in a Git repo and pull from upstream, the pull may stop with an error message and tell you to use git stash. Stashing your changes, pulling, and then re-applying your changes is effectively a rebase, although it's a rebase that lives entirely outside of the VCS history. There are other uses for stashing, but this is where I most frequently run into it.

Some people maintain patches or patch series in quilt, especially since this is basically how you modify Debian and RPM format source packages. As you either evolve the patches or change the base version of the software you're patching, you're once again effectively rebasing. Some projects capture the development of these patch series in VCS repos in one way or another, but I don't think it's very common to maintain them in the VCS as a non-rebasing form and then materialize them as patches for your packaging format. And unless you're quite deep into the project's development ecology (so that you can easily set it up and maintain a local version), you probably don't do this for your local patches and patch series.

Even Mercurial supports this sort of rebasing. In fact, Mercurial is more liberal than Git is. If you have uncommitted changes in a Mercurial repository and pull updates that change the same files, Mercurial will go ahead to try to merge your changes with the upstream changes; you only need to stash or manually reconcile the merge if Mercurial detects a change conflict. Also, like Git, in Mercurial you can "shelve" uncommitted changes, change the checked out version of the repo, and unshelve them, effectively rebasing your changes on top of the new version.

What all of these operations have in common, and how they differ from 'git rebase', is that they don't take existing VCS history and rewrite it (in the Git sense). In one way or another, all of them work on changes that are living outside your VCS.

My long-standing view is that VCSes are user interfaces to the formal mathematics of version control. To me, it feels at best somewhat odd that version control systems condition their support for the general operation of rebasing on whether or not you've chosen to capture your changes in the VCS, with not capturing your changes in the VCS often leaving you better off. I cannot help but think that if people are resorting to quilt on top of a VCS repo, something has gone wrong.