[Aptitude-devel] Rebasing published software and avoid git revert/merge
mandyke at gmail.com
Wed Sep 5 03:55:07 BST 2012
Two months ago I release aptitude 0.6.9 to experimental. Many of
those changes will not make it in to Wheezy and I am refactoring and
publishing some of the updates under 0.6.8.n. This refactoring is
proving to be a better base of development going forward so I plan to
forget about 0.6.9 and continue the stable updates using 0.6.10.
What I have is two git branches with some overlapping and some unique
changes on each. The 0.6.9 branch also has some changes which I will
back out completely in the short term.
C'--E stable-0.6 (0.6.8.1, unstable/testing)
A---B---C---D master (0.6.9.1, experimental)
I wish to make stable-0.6 the new master while avoiding a merge or
revert+merge on master (the difference between them is quite large).
There is the published git history . I am the author of all
changes which would disappear by replacing master, other changes are
first going to be moved to the stable-0.6 branch.
My plan is to:
- ask that .9 be removed from experimental;
- delete published master (that is, “git push origin :master”);
- rename stable-0.6 to master and push;
- repeat previous two steps for the git-buildpackage branches (debian
- release next version as 0.6.10 without NEWS/changelog entries for .9
and a note saying that release has been reverted;
- some bugs fixed in .9 will be marked as found in .10;
Is this approach sane?
I realise that deleting master and republishing will disrupt
developers the next time they git pull. Does anyone know how this
would also affect services like launchpad.net and ohloh.net, which
also pull from that branch?
More information about the Aptitude-devel