[Aptitude-devel] Rebasing published software and avoid git revert/merge

Florian Schlichting fschlich at ZEDAT.FU-Berlin.DE
Wed Sep 5 08:41:04 BST 2012

On Wed, Sep 05, 2012 at 03:14:23PM +0800, Daniel Hartwig wrote:
> On 5 September 2012 14:55, Florian Schlichting
> <fschlich at zedat.fu-berlin.de> wrote:
> > Alternatively, you could revert the entirety of A..master and then
> > cherry-pick (or rebase, or merge) A..stable-0.6 onto that and call it
> > master. That way, you preserve linear history and still have a master
> > branch identical to stable-0.6.
> The revert would be huge, which is why I wanted to avoid it.  You are
> right that this is less disruptive to others who pull from the repo.

I'd say if you have more than two people who pulled from the repo, avoid
it. Git doesn't care how big the revert is, the important thing IMHO is
that by first reverting and then merging or cherry-picking, you are not
going to have merge conflics, so it's pain-free.

> Any thoughts about release .10 with most of .9 changes reverted, and
> missing the NEWS entry for .9?

NEWS is what's shown to people when they upgrade, and it's purely
informational: if there's nothing your users need to know when upgrading
to .10, ommit it. Particularly if users upgrading from .8 would be shown
confusing things for .9 that are no longer relevant in .10. If you're
worried about "rewriting history", why not make a note about the
deletion in d/changelog?


More information about the Aptitude-devel mailing list