Comment 3 for bug 243150

Revision history for this message
Ulrik Mikaelsson (rawler) wrote :

I've been investigating this a little, and I see one thing that haven't explicitly mentioned, namely changing commit-messages.

I think adding extra commands, edit-plan and execute-plan would only make it unnecessarily complex, and also less usable, since -i would always be invoked right before editing and executing the plan.

One approach would be to change the persistent merge formats slightly, so that there is a $checkout/rebase-orig, containing only the reference to the original rebased revisiong.

Then there would be a $checkout/rebase-todo, containing only the actions left to do, looking something like:
# Bazaar rebase plan 2
# valid actions are:
# checkout <orig>
# commit <message>
# edit
# merge <revspec>
checkout <orig revid>
merge <first_revision>
commit "Some nice message"
merge <second_revision>
commit "Some other nice message"
merge <third_revision>

So, if the user specifies rebase -i, bzr would generate a todo/plan, drop to $EDITOR and let the user edit the plan (including introducing edit-points, edit commit-messages, squashing commits, etc...)

Then on successful editor-exit, rebase would execute pretty much as before, performing all actions in the order they appear. One thing that could use some special mention would be splitting revisions, which could simply be done by an edit-action, letting the user manually commit some of the desired stuff, and then rebase-continue.

This workflow, and changing the plan-formats, would have a few advantages over what's suggested before:
 * In the normal case, the user does only have to add -i, and do minimal editing for a trivial re-write.
 * If a rebase-merge fails (even when not -i were specified), one could have a rebase_edit command, editing $checkout/rebase-todo, so that the user is given the option to skip this particular revision and continue. (An example would be a revision that were submitted upstream, but were changed a lot to make the merge fail.)
 * Most users looking for interactive rebase to change history are probably coming from git. This would make them feel pretty much at home, closely resembling the git workflow.

I miss this feature enough to have a go at it, unless someone else is willing (or have already worked on it). So please, if you have ideas/work done, please tell me soon, to avoid duplicate efforts.