bzr rebase doesn't provide --interactive

[John Carr]

As per discussion with thumper who had seen this use case. What if you've worked on a feature and its bigger than you would normally like when sending to a reviewer.

In Git, you do an interactive rebase to squash commits into a patch series. The reviewer then just looks at the reduced history.

This sucks - you destroy history. *Technically* its still there, hidden away in the reflog, but anyway.

If looms are the answer - how can i split an existing branch into seperate looms, preserving history but also providing a "cleaned" and "nice" and "beautiful" patch (bundle?) series for a reviewer.

Otherwise, what is the answer?

[Jonathan Lange (jml)]

On Fri, Dec 12, 2008 at 9:26 AM, John Carr <email address hidden> wrote:
> If looms are the answer - how can i split an existing branch into
> seperate looms, preserving history but also providing a "cleaned" and
> "nice" and "beautiful" patch (bundle?) series for a reviewer.
>

You don't split a branch into separate looms. You make a branch a
loom, and then create threads within that loom. Each thread
corresponds to a patch that you'll send to reviewer.

One big difference between looms and rebase is that you can start
working that way as soon as you start your branch. For each local
commit, you can decide which thread it belongs in.

The flip side is that it's not obvious how to move from an existing
big branch into a bunch of threads in a loom. What I'd do is something
like:
    bzr branch trunk new-loom
    cd new-loom
    bzr loomify --base trunk
    bzr create-thread name-of-patch-1
    bzr merge ../mega-branch
    bzr shelve
      (select stuff relevant to patch-1)
    bzr ci
    bzr create-thread name-of-patch-2
    bzr unshelve
      (select stuff relevant to patch-2)
    bzr ci
    [Rinse and repeat]

> Otherwise, what is the answer?
>

Also, the bzr rebase plugin exists.

jml

[John Carr (johncarr)]

bzr rebase doesnt have (or didnt) an interactive option for squashing and editing commits. Also it destroys history, and as Bazaar prides its self on not destorying history i don't favor that option.

Terminology fail on my part, by "splitting into looms" i mean threads in a loom. Very glad for the look recipe. Does this recipe preserve history?

I remember lifeless showing me a interactive merge - could i repeatedly interactively merge into multiple threads (each time there would be less for me to merge)? Would that preserve history?

[Jonathan Lange (jml)]

On Fri, Dec 12, 2008 at 10:21 AM, John Carr <email address hidden> wrote:
> Terminology fail on my part, by "splitting into looms" i mean threads in
> a loom. Very glad for the look recipe. Does this recipe preserve
> history?
>

Yes, although it doesn't do anything magical to say "this commit that
I did ages ago should have been done in that thread", which is a
shame. The first "merge" really does pull in all the history from the
branch, and future commits extend the branch history.

The main point here is that threads can be submitted as patches and
trunk gets to keep a pretty left-most history.

> I remember lifeless showing me a interactive merge - could i repeatedly
> interactively merge into multiple threads (each time there would be less
> for me to merge)? Would that preserve history?
>

Couldn't say, I've never used interactive merge.

jml