confusing status/diff output when merging two trees with the same file added on each side

[Colin Watson]

If you add the same file in 2 branches and then merge them, you get the standard 'files conflict' and one gets a '.moved' path.

However, in 0.15+ (also tested with bzr.dev 2464) it marks the original file as 'unknown'.

Steps to reproduce:

  bzr init A
  cd A
  touch one
  bzr add one
  bzr commit -m 1
  bzr branch . ../B
  touch two
  bzr add two
  bzr commit -m 2
  cd ../B
  touch two
  bzr add two
  bzr commit -m 'alt 2'
  bzr merge ../A

At this point you get a file path conflict with bzr merge reporting:
+N two
R two => two.moved
Conflict adding file two. Moved existing file to two.moved.
1 conflicts encountered.

and bzr status reports:
renamed:
  two => two.moved
unknown:
  two
conflicts:
  Conflict adding file two. Moved existing file to two.moved.
pending merges:
  John Arbash Meinel 2006-11-25 2

Colin originally reported the same reproducable bug from:

  bzr get -r140 http://bazaar.launchpad.net/~ubuntu-core-dev/libdebian-installer/ubuntu/
  bzr get -r146 http://bazaar.launchpad.net/~vcs-imports/libdebian-installer/main/
  cd ubuntu
  bzr merge -r146 ../main

...

I tried to merge this as follows:

$ bzr merge -r146 ../main
+N HACKING
+N src/system/subarch-armeb-linux.c
+N src/system/subarch-armel-linux.c@
+N src/system/subarch-x86-linux.c
 M configure.ac
 M debian/changelog
 M src/system/Makefile.am
-D src/system/subarch-armeb-linux.c
 M src/system/subarch-powerpc-linux.c
R src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
Text conflict in configure.ac
Text conflict in debian/changelog
Conflict adding file src/system/subarch-x86-linux.c. Moved existing file to src/system/subarch-x86-linux.c.moved.
3 conflicts encountered.

That's fine - these conflicts are expected. But:

$ bzr renames
src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
$ bzr added
src/system/subarch-armeb-linux.c
HACKING
src/system/subarch-x86-linux.c
src/system/subarch-armel-linux.c
$ bzr status
[...]
renamed:
  src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
[...]
unknown:
[...]
  src/system/subarch-x86-linux.c

What's going on? Why does 'bzr added' say it's been added, but 'bzr status' say it's unknown? Likewise, 'bzr diff' doesn't show the added file. I did 'rm src/system/subarch-x86-linux.c.moved; bzr resolve src/system/subarch-x86-linux.c', and this resolves the conflict but still shows the file as unknown in status output. Eventually I decided to try committing it anyway and got:

$ bzr commit -m 'merge from Debian 0.51'
missing src/system/subarch-x86-linux.c.moved
added HACKING
modified configure.ac
modified debian/changelog
modified src/system/Makefile.am
added src/system/subarch-armeb-linux.c
added src/system/subarch-armel-linux.c
modified src/system/subarch-powerpc-linux.c
added src/system/subarch-x86-linux.c
deleted src/system/subarch-armeb-linux.c
deleted src/system/subarch-x86-linux.c
Committed revision 141.

After this, the branch now does seem to be in the right state. However, I'm used to relying on the status output to reassure me that the right thing is going to be committed, and it definitely failed to reassure me here.

I'm using bzr 0.15.0 and had fully upgraded branch formats throughout.

[Bubba Siggler (bud3)]

Hi Robert,
I ran a bzr.dev selftest got a trace back that ask to be sent to bazaar ubuntu

if I could help let me know it's not as simple for some of us.

best regards

bubba

On 4/26/07, Colin Watson <email address hidden> wrote:
> Public bug reported:
>
> I'm working on http://bazaar.launchpad.net/~ubuntu-core-dev/libdebian-
> installer/ubuntu/ (at revision 140), and was trying to merge up to
> revision 146 of http://bazaar.launchpad.net/~vcs-imports/libdebian-
> installer/main/. The same file, src/system/subarch-x86-linux.c, was
> added (as it happens, with the same contents) in both branches after the
> last merge, and now I'd like to end up with the vcs-imports file-id in
> both branches so that future merges are straightforward. This is a
> fairly normal thing to happen for me when I add a file both in Ubuntu
> and in the upstream Subversion repository, usually because the Ubuntu
> release cycle is at a point where I can't just do it upstream and wait
> for it to land.
>
> I tried to merge this as follows:
>
> $ bzr merge -r146 ../main
> +N HACKING
> +N src/system/subarch-armeb-linux.c
> +N src/system/subarch-armel-linux.c@
> +N src/system/subarch-x86-linux.c
> M configure.ac
> M debian/changelog
> M src/system/Makefile.am
> -D src/system/subarch-armeb-linux.c
> M src/system/subarch-powerpc-linux.c
> R src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
> Text conflict in configure.ac
> Text conflict in debian/changelog
> Conflict adding file src/system/subarch-x86-linux.c. Moved existing file to src/system/subarch-x86-linux.c.moved.
> 3 conflicts encountered.
>
> That's fine - these conflicts are expected. But:
>
> $ bzr renames
> src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
> $ bzr added
> src/system/subarch-armeb-linux.c
> HACKING
> src/system/subarch-x86-linux.c
> src/system/subarch-armel-linux.c
> $ bzr status
> [...]
> renamed:
> src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
> [...]
> unknown:
> [...]
> src/system/subarch-x86-linux.c
>
> What's going on? Why does 'bzr added' say it's been added, but 'bzr
> status' say it's unknown? Likewise, 'bzr diff' doesn't show the added
> file. I did 'rm src/system/subarch-x86-linux.c.moved; bzr resolve
> src/system/subarch-x86-linux.c', and this resolves the conflict but
> still shows the file as unknown in status output. Eventually I decided
> to try committing it anyway and got:
>
> $ bzr commit -m 'merge from Debian 0.51'
> missing src/system/subarch-x86-linux.c.moved
> added HACKING
> modified configure.ac
> modified debian/changelog
> modified src/system/Makefile.am
> added src/system/subarch-armeb-linux.c
> added src/system/subarch-armel-linux.c
> modified src/system/subarch-powerpc-linux.c
> added src/system/subarch-x86-linux.c
> deleted src/system/subarch-armeb-linux.c
> deleted src/system/subarch-x86-linux.c
> Committed revision 141.
>
> After this, the branch now does seem to be in the right state. However,
> I'm used to relying on the status output to reassure me that the right
> thing is going to be committed, and it definitely failed to reassure me
> here.
>
> I'm using bzr 0.15.0 and ha...

[John A Meinel (jameinel)]

I would guess this is related to bug #109993, or bug #105479, both of which have been fixed in a recent bzr.dev (the 109993 was just merged today).

Could yuo give a try using the latest bzr.dev? (the fix for 109993 is, unforunately, not in 0.16rc1)

[Colin Watson (cjwatson)]

Smaller test case:

$ mkdir a
$ cd a
$ bzr init
$ touch foo
$ bzr add foo
added foo
$ bzr commit -m start
added foo
Committed revision 1.
$ cd ..
$ bzr branch a b
Branched 1 revision(s).
$ cd b
$ touch subarch-x86-linux.c
$ bzr add subarch-x86-linux.c
added subarch-x86-linux.c
$ bzr commit -m add
added subarch-x86-linux.c
Committed revision 2.
$ cd ../a
$ touch subarch-x86-linux.c
$ bzr add subarch-x86-linux.c
added subarch-x86-linux.c
$ bzr commit -m add
added subarch-x86-linux.c
Committed revision 2.
$ cd ../b
$ bzr merge ../a
+N subarch-x86-linux.c
R subarch-x86-linux.c => subarch-x86-linux.c.moved
Conflict adding file subarch-x86-linux.c. Moved existing file to subarch-x86-linux.c.moved.
1 conflicts encountered.
$ bzr status
renamed:
  subarch-x86-linux.c => subarch-x86-linux.c.moved
unknown:
  subarch-x86-linux.c
conflicts:
  Conflict adding file subarch-x86-linux.c. Moved existing file to subarch-x86-linux.c.moved.
pending merges:
  Colin Watson 2007-04-26 add

[Colin Watson (cjwatson)]

Reproduces identically with bzr.dev r2464.

[John A Meinel (jameinel)]

This is another dirstate edge-case regression

[Bubba Siggler (bud3)]

On 4/26/07, John A Meinel <email address hidden> wrote:
> This is another dirstate edge-case regression
>
> ** Description changed:
>
> - I'm working on http://bazaar.launchpad.net/~ubuntu-core-dev/libdebian-
> - installer/ubuntu/ (at revision 140), and was trying to merge up to
> - revision 146 of http://bazaar.launchpad.net/~vcs-imports/libdebian-
> - installer/main/. The same file, src/system/subarch-x86-linux.c, was
> - added (as it happens, with the same contents) in both branches after the
> - last merge, and now I'd like to end up with the vcs-imports file-id in
> - both branches so that future merges are straightforward. This is a
> - fairly normal thing to happen for me when I add a file both in Ubuntu
> - and in the upstream Subversion repository, usually because the Ubuntu
> - release cycle is at a point where I can't just do it upstream and wait
> - for it to land.
> + If you add the same file in 2 branches and then merge them, you get the
> + standard 'files conflict' and one gets a '.moved' path.
> +
> + However, in 0.15+ (also tested with bzr.dev 2464) it marks the original
> + file as 'unknown'.
> +
> + Steps to reproduce:
> +
> + bzr init A
> + cd A
> + touch one
> + bzr add one
> + bzr commit -m 1
> + bzr branch . ../B
> + touch two
> + bzr add two
> + bzr commit -m 2
> + cd ../B
> + touch two
> + bzr add two
> + bzr commit -m 'alt 2'
> + bzr merge ../A
> +
> + At this point you get a file path conflict with bzr merge reporting:
     Hi John,
      I was entering the top until I got the conflict here above.To
continue to follow this part I recall that two file should not touch
is that right.

      best regards

      bubba

> + +N two
> + R two => two.moved
> + Conflict adding file two. Moved existing file to two.moved.
> + 1 conflicts encountered.
> +
> + and bzr status reports:
> + renamed:
> + two => two.moved
> + unknown:
> + two
> + conflicts:
> + Conflict adding file two. Moved existing file to two.moved.
> + pending merges:
> + John Arbash Meinel 2006-11-25 2
> +
> +
> + Colin originally reported the same reproducable bug from:
> +
> + bzr get -r140 http://bazaar.launchpad.net/~ubuntu-core-dev/libdebian-installer/ubuntu/
> + bzr get -r146 http://bazaar.launchpad.net/~vcs-imports/libdebian-installer/main/
> + cd ubuntu
> + bzr merge -r146 ../main
> +
> + ...
>
> I tried to merge this as follows:
>
> $ bzr merge -r146 ../main
> +N HACKING
> +N src/system/subarch-armeb-linux.c
> +N src/system/subarch-armel-linux.c@
> +N src/system/subarch-x86-linux.c
> M configure.ac
> M debian/changelog
> M src/system/Makefile.am
> -D src/system/subarch-armeb-linux.c
> M src/system/subarch-powerpc-linux.c
> R src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
> Text conflict in configure.ac
> Text conflict in debian/changelog
> Conflict adding file src/system/subarch-x86-linux.c. Moved existing file to src/system/subarch-x86-linux.c.moved.
> 3 conflicts encountered.
>
> That's fine - these conflicts are expected. But:
>
> $ bzr renames
> src/system/subarch-x86-linux.c => src/system/subarch-x86-linux.c.moved
> $...

[John A Meinel (jameinel)]

This seems to be another ordering issue. If I:

  cd B
  bzr merge ../A
  bzr status
added:
  two
renamed:
  two => two.moved
conflicts:
  Conflict adding file two. Moved existing file to two.moved.
pending merges:
  John Arbash Meinel 2007-04-26 2

Which is correct. But if I:
  cd A
  bzr merge ../B
  bzr status
renamed:
  two => two.moved
unknown:
  two
conflicts:
  Conflict adding file two. Moved existing file to two.moved.
pending merges:
  John Arbash Meinel 2007-04-26 alt 2

So it seems to be another "matching on first entry rather than second" bug. Same as bug 109993. But maybe only for renames? (Rather than 'absent')

[John A Meinel (jameinel)]

There is a fix available on the related branch.