About feature branches for patch handling and reverting to old states.

Mon, 01 Aug 2011 12:12:44 +0200
answers

Now that the debconf videos are available (big THANKS to the video team), I was able to watch the talk about packages in git at Debconf11 and wanted to share some insights:

Feature branches
I've looked a long time into topgit, and like many other gave up. I think there is one big problem: It is not compatible with git.
Git tracks the history of commits. Everything that is in the history is assumed to be already applied. So if you merge something with a change applied and reverted with something with a change applied, the logical conclusion for git is to not apply it (or rather also apply the revert).
This means that if you have multiple feature branches on top of each other, you cannot easily remove a branch from under the other. You can also not easily switch the order of patches. There are many ideas floating around how to work around this, but I personally would not wait until some manages to finish topgit or some replacement of it with that functionality.

Reverting to an older state or branching off
The other problem with many feature branches is that while due to aggressive merging you can fast-forward to a newer state, reverting to an older state of all the branches is relatively complicated.
With the "rebased patch branch merged into you debian branch history" approach of git-dpm on the other hand, branching of a state is extremely simple:
git checkout -b squeeze reprepro-debian-4.2.0-2
for example is the only thing that was needed to branch of a branch for stable updates. Reverting to a previous state with git reset --hard is not much more complicated (at most you need to remove the upstream and patched branches, if they are needed they will be recreated anyway).