bzr merge fails with changed/removed file, hard to recover
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Situation: some SuSE guy autotoolized pmount a while ago, which involved quite a lot of file renames, moves, and deletions. The autotoolized version which branched off an earlier pmount version is at http://
I tried to merge this branch against pmount main; a snapshot of the version I merged to is at http://
$ bzr merge ../pmount-
bzr: WARNING: Diff3 conflict encountered in /home/martin/
bzr: ERROR: Contents mismatch deleting /home/martin/
at /usr/lib/
the CHANGES warning is fine, I have to resolve a conflict; but the ERROR spoils the merge in two different ways: first, it is not helpful in the first place, and second it leaves the tree in an inconsistent state:
$ bzr status
removed:
pmount-hal.1
pmount-hal.c
pmount.allow
pumount.1
pumount.c
modified:
CHANGES
unknown:
CHANGES.BASE
CHANGES.OTHER
CHANGES.THIS
bzr-tree-change
conflicts:
CHANGES
That means that quite a bunch of the source files have been removed, but they weren't created in the new location (etc/pmount.allow, or src/pmount.c) (these files have been moved in the autotools branch). The bzr-tree-change directory clutters up the working tree, and bzr revert fails:
p$ bzr revert
bzr: ERROR: bzr-tree-change contains files from a previous failed merge operation.
at /usr/lib/
After manually removing the directory, bzr revert works better: it adds back the removed files and just leaves the CHANGES conflict laying around (which is still a bug, but sucks much less, and should be in a separate report).
I was able to work around this bug by manually removing Makefile before merging, BTW.
Changed in bzr: | |
status: | New → Fixed |