2021-11-01
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.