Cannot merge -r 0..-1 in an empty branch

[Dato Simó]

I sometimes use `bzr merge -r 0..-1` to merge a branch with some files
on top on another branch which I now want to contain those files.

Today I wanted to do that, in an empty branch. And it didn't work. I
know it's something omewhat strange to do, but maybe it ought to work?

This works:

  % bzr init bin
  % cd bin
  % bzr ci --unchanged -m 'Work around bug.'
  % bzr merge -r 0..-1 ../misc
  % bzr st
  added:
      foo
      bar
  pending merges:
      [etc.]

Without the dummy commit:

  % bzr init bin
  % cd bin
  % bzr merge -r 0..-1 ../misc
  % bzr st
  working tree is out of date, run 'bzr update'

  % bzr update
  -D foo
  -D bar
  All changes applied successfully.
  bzr: ERROR: Reserved revision-id {null:}

  % bzr st
  working tree is out of date, run 'bzr update'
  removed:
    foo
    bar

 affects /products/bzr

[Aaron Bentley (abentley)]

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

Adeodato Simó wrote:
> Public bug reported:
>
> I sometimes use `bzr merge -r 0..-1` to merge a branch with some files
> on top on another branch which I now want to contain those files.
>
> Today I wanted to do that, in an empty branch. And it didn't work. I
> know it's something omewhat strange to do, but maybe it ought to work?

It can't work with our current way of representing working directories
and revisions.

The last-committed revision is *usually* listed as parent[0], and merges
are listed as parent[1:]. But in a tree with no commits, there are *no*
parents, and so if you do a merge, that becomes parent[0]. We should
probably disallow merge in that case, since you'll get wacky behavior.

In theory, this could be fixed by changing our working tree and revision
representations to list null: as a parent, but it seems like a lot of
work for a corner case like this.

> % bzr update
> -D foo
> -D bar
> All changes applied successfully.
> bzr: ERROR: Reserved revision-id {null:}

^^ This bug should be fixed.

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

iD8DBQFHXaCY0F+nu1YWqI0RAmRoAKCC8Z06n5FGHaMC7UZSzW6r9YbehwCggLcg
UHoYMcQtr3oBr68gpzmNU1A=
=TvN9
-----END PGP SIGNATURE-----

[Dato Simó (dato)]

> ** This bug has been marked a duplicate of bug 56663
> merge degrades to pull in an empty branch from bzr 0.10 on

Well, at the moment plain `merge` (without -r argument) does not degrade
to pull. It hits this as well:

> > % bzr update
> > -D foo
> > -D bar
> > All changes applied successfully.
> > bzr: ERROR: Reserved revision-id {null:}

> ^^ This bug should be fixed.

So maybe there should be two separate bug numbers: one for having merge
do a real merge on empty branches, and leave it open, another for the
one you said "this one should be fixed".

[Aaron Bentley (abentley)]

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

Adeodato Simó wrote:
> *** This bug is a duplicate of bug 56663 ***
> https://bugs.launchpad.net/bugs/56663
>
>> ** This bug has been marked a duplicate of bug 56663
>> merge degrades to pull in an empty branch from bzr 0.10 on
>
> Well, at the moment plain `merge` (without -r argument) does not degrade
> to pull.

What's meant is that merge sets the last-revision of empty trees.
That's true whether or not -r 0..-1 is specified. In fact, merge in an
empty branch is equivalent to merge -r 0..-1

> So maybe there should be two separate bug numbers: one for having merge
> do a real merge on empty branches, and leave it open, another for the
> one you said "this one should be fixed".

Sure.

Aaron

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

iD8DBQFHXbE+0F+nu1YWqI0RAnckAJ45edF3F1XF7+P05ONFFJCabT9jpQCfUtWl
Hp3BfK/EdEDxCOrdoMUjjVE=
=b6Lx
-----END PGP SIGNATURE-----