Comment 3 for bug 152008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel пишет:
> I did add a bit of discussion to:
> http://bazaar-vcs.org/Specs/RecordCherryPick
>
> Since I didn't know of a better place to put it.
>
> I also realized something else, though. Which is that you can do:
>
> cd mainline
> bzr merge ../feature
> bzr commit -m "merging feature" # revno 10
> <hack hack, commit commit>
> <oops, we don't want 'feature'>
> bzr merge -r 10..9
> bzr commit -m "removing feature" # revno 15
> cd ../feature
> bzr merge ../mainline -r 14
> bzr commit -m "Getting into sync with mainline"

> bzr merge ../mainline
> bzr revert . # Remove the 'remove feature' changes

I'm not sure about last 2 commands. AFAIK, revert will remove pending merge,
so next commit will be pointless. Martin did some improvement in this
area to simply forget pending merges, but not changes. Something
like
bzr revert --forget-merge

> bzr commit -m "Override the feature removal"
>
>
> This is a bit... difficult, but it records what you want.
> The mainline still considers that it has reverted the feature, but the feature branch now has a revision which restores everything. It should even do the right thing for annotations (leaving them at the line that originally modified them, not the new merge/revert revision).
>
> It is certainly possible that we could write a plugin to help automate
> this, as it is all pretty systematic. You could even do something like:
>
> bzr unmerge ../feature
>
> And have it do all the steps to both '.' and to '../feature', having it
> detect where in '.' feature was merged, revert those changes, etc.
>
> The biggest problem is probably that you have to do the "bzr merge
> ../mainline -r 14". And bring the feature branch to the tip of mainline.
> Which could be problematic.
>
> The other alternative was to rebase, which would look something like:
>
> cd project
> mv mainline old_mainline
> bzr branch old_mainline mainline -r 9
> bzr rebase ../mainline -r 10..-1
>
> This creates new commits in mainline, which means that if someone is
> mirroring your branch, they need to "pull --overwrite" as the history
> has now diverged. This is a bit "cleaner" overall, but it does mean
> going back and hiding history, rather than annotating it to indicate
> that you want to do something different.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHD8iDzYr338mxwCURAvZqAJsHwetsOWoQKmggCJ5Yzq5maFHykACfRKmh
WFDGXrWFM5EkM1GvGnApQR8=
=FxLv
-----END PGP SIGNATURE-----