support rebasing a treeless branch

[Juanma Barranquero]

Currently rebase does not support rebasing in a treeless branch:

C:\emacs\test> bzr rebase
bzr: ERROR: No WorkingTree exists for "file:///C:/emacs/test/.bzr/checkout/".

However, it is a perfectly sensible thing to do; in my case, test/ has been branched from trunk/, but has modifications not in trunk/, committed via a checkout + switch (used to emulate colocated branches). I want test/ to be kept up-to-date with trunk/.

Now, the only way to rebase test is

   cd test
   bzr checkout
   bzr rebase
   bzr remove-tree

which is slow and wasteful.

[Max Bowsher (maxb)]

But, the act of rebasing includes merging. It's logically impossible to merge without a working tree - the same applies to rebase, as far as I can see.

[Juanma Barranquero (lekktu)]

> But, the act of rebasing includes merging. It's logically impossible to
> merge without a working tree

When you say "a working tree", do you mean a checked out working tree?

Because merging in a "treeless" working tree (a working tree with no
files) it's of course logically possible: it's equivalent to having
the files checked out and no local changes. As you can see in my
example, you *can* do it right now:

   cd test
   bzr checkout
   bzr rebase
   bzr remove-tree

which has the intended effect: bring changes from trunk into test,
rebasing the modifications in test that weren't in trunk.

    Juanma

[Jelmer Vernooij (jelmer)]

I'm not sure if we should support this.

The problem is that the rebase may be interrupted by conflicts that have
to be resolved by the user. To be able to allow the user to resolve
those conflicts, we need a working tree.

We should be able to get away with not using a tree as long as we don't
hit conflicts, but this can mean that if you rebase a lot of revisions
and hit a conflict you have to start over again from scratch *with* a
working tree.

[Juanma Barranquero (lekktu)]

On Sun, Feb 7, 2010 at 14:49, Jelmer Vernooij <email address hidden> wrote:

> We should be able to get away with not using a tree as long as we don't
> hit conflicts, but this can mean that if you rebase a lot of revisions
> and hit a conflict you have to start over again from scratch *with* a
> working tree.

That could be solved, for treeless branches, by rebase doing a
checkout when there are conflicts, and having a "rebase --continue".
When rebase finishes OK, it does remove-tree and leaves the branch
treeless again. That would avoid doing the checkout in all
conflictless rebases, and would do at most one checkout/remove-tree
when there are conflicts. So, it's equivalent to a "checkout; rebase;
remove-tree" sequence, but potentially faster and more efficient (in
some cases).

    Juanma

[Jelmer Vernooij (jelmer)]

On Sun, 2010-02-07 at 14:39 +0000, Juanma Barranquero wrote:
> On Sun, Feb 7, 2010 at 14:49, Jelmer Vernooij <email address hidden> wrote:
>
> > We should be able to get away with not using a tree as long as we don't
> > hit conflicts, but this can mean that if you rebase a lot of revisions
> > and hit a conflict you have to start over again from scratch *with* a
> > working tree.
>
> That could be solved, for treeless branches, by rebase doing a
> checkout when there are conflicts, and having a "rebase --continue".
we already have a "bzr rebase-continue" command.

> When rebase finishes OK, it does remove-tree and leaves the branch
> treeless again. That would avoid doing the checkout in all
> conflictless rebases, and would do at most one checkout/remove-tree
> when there are conflicts. So, it's equivalent to a "checkout; rebase;
> remove-tree" sequence, but potentially faster and more efficient (in
> some cases).
If you're running rebase more than once for a particular branch it's a
lot more efficient to keep the checkout around because that allows you
to not have to recreate the checkout at all.

I'm not convinced there's a need for this so won't work on this myself,
but I'll take patches.

  status triaged
  importance wishlist

Cheers,

Jelmer