Handling complicated rebase scenarios

Bug #886554 reported by Kirill Müller on 2011-11-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Sometimes I have the following use case:


I need to rebase both B and C against A'. This occurs after rebasing B against A' (--> B') and C against B':


However, the correct schema would be this:


I have proposed ignoring the (pointless) commits of B in https://bugs.launchpad.net/bzr-rewrite/+bug/886542 . However, this could be handled better if B' "knew" somehow which commits of C are already integrated. Would it be an option to add the corresponding original commit of B as parent of each commit of B'? What would be the implications of this, especially considering rebase -i/histedit where the order of commits can change?

Jelmer Vernooij (jelmer) wrote :

rebase already sets revision properties that indicate what revision a new revision was based on.

You could potentially use this information.

Changed in bzr-rewrite:
status: New → Triaged
Jelmer Vernooij (jelmer) wrote :

I'm not really sure what this bug report is asking for - it seems to be a dupe of bug 886542 mostly.

Changed in bzr-rewrite:
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers