Bazaar

"bzr remerge" should not remerge resolved conflicts

Bug #409555 reported by Eric Siegerman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Low
Unassigned

Bug Description

Suppose I do a merge that reports conflicts in several files. I fix some of the files and "bzr resolve" them. I then do "bzr remerge", in an attempt to make the conflicts in remaining files more tractable.

I would expect that remerge would leave alone any files that have been "bzr resolve"ed, but instead it remerges them, and brings them back into "conflicted" state.

Workarounds:
  - specify the files to be remerged, using "bzr remerge filename[s]"
  - if you've already re-conflicted some files by running "bzr remerge" with no filenames, the manually resolved version of each such file will be in filename.THIS.

To reproduce:
First, run the following pure shell script to set things up:
# ===== BEGIN =====
# Initial setup
bzr init a
cat >a/f1 <<EOF
a
b
c
EOF
cat >a/f2 <<EOF
1
2
3
EOF
bzr add a
bzr commit a '-mAdd files'

bzr branch a b

# Create conflicts in f1 and f2
echo >>a/f1 new in a
echo >>a/f2 new in a
bzr commit a '-mmods in a'

echo >>b/f1 new in b
echo >>b/f2 new in b
bzr commit b '-mmods in b'

# Merge a into b
cd b
bzr merge

# Resolve conflict in f1
mv f1.BASE f1
echo >>f1 "new (resolved)"
bzr resolve f1

# ===== END =====

Now run the following commands (from here on is NOT a runnable shell script):
#
# Verify the state before tripping the bug. Note that, as expected, no
# conflict is reported on f1.
#

$ bzr stat
modified:
  f1
  f2
unknown:
  f2.BASE
  f2.OTHER
  f2.THIS
conflicts:
  Text conflict in f2
pending merge tips: (use -v to see all merge revisions)
  Eric Siegerman 2009-08-05 mods in a

#
# Trip the bug. This should not report a conflict on f1, since it should not
# attempt to remerge f1 in the first place.
#

$ bzr remerge --show-base
Text conflict in f1
Text conflict in f2
2 conflicts encountered.

#
# Sure enough, the conflict markers are back (but note that
# the TREE version contains my manual resolution of the
# conflict.
#

$ cat f1
a
b
c
<<<<<<< TREE
new (resolved)
||||||| BASE-REVISION
=======
new in a
>>>>>>> MERGE-SOURCE
$

Revision history for this message
John A Meinel (jameinel) wrote :

I'm pretty sure that "bzr remerge" is intended as "please re-try the merge from scratch". What you might be looking for is:

bzr remerge `bzr conflicts --text`

Though perhaps:
  bzr remerge --only-conflicts
Or something along those lines would be a better way of invoking it?

Revision history for this message
Alexander Belchenko (bialix) wrote :

John, actually reading the help for remerge user get the impression that remerge works only wih conflicted files (i.e. those marked as conflicted). See:

Examples:
    Re-do the merge of all conflicted files, and show the base text in
    conflict regions, in addition to the usual THIS and OTHER texts:

        bzr remerge --show-base

Note: "Re-do the merge of all *conflicted* files" -- not all files!

This bug makes remerge the dangerous tool.

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 409555] Re: "bzr remerge" should not remerge resolved conflicts

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

Alexander Belchenko wrote:
> John, actually reading the help for remerge user get the impression that
> remerge works only wih conflicted files (i.e. those marked as
> conflicted). See:
>
> Examples:
> Re-do the merge of all conflicted files, and show the base text in
> conflict regions, in addition to the usual THIS and OTHER texts:
>
> bzr remerge --show-base
>
> Note: "Re-do the merge of all *conflicted* files" -- not all files!
>
> This bug makes remerge the dangerous tool.
>

So I'd wait for a ruling from someone like Aaron who actually wrote the
tool to know what he was thinking.

I see that the code *can* support "interesting_ids" but has the code:

interesting_ids = None
...
if file_list is not None:
...
else:
    # Remerge only supports resolving contents conflicts
    allowed_conflicts = ('text conflict', 'contents conflict')
    restore_files = [c.path for c in conflicts
                     if c.typestring in allowed_conflicts]
_mod_merge.transform_tree(tree, tree.basis_tree(), interesting_ids)

So in other words, if you don't supply a file_list then interesting_ids
is None, and the "transform_tree" step is basically a "revert" and then
"merge" comes later on.

If we wanted partial behavior we could do something like:

else:
  ...
  interesting_ids = set([c.file_id for c in conflicts
                         if c.typestring in allowed_conflicts
                            and c.file_id is not None])

Or something along those lines.

But it *is* written to basically do "bzr revert; bzr merge" when you do
"bzr remerge" with no arguments.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkp65T8ACgkQJdeBCYSNAAO4JgCeN77+rYELO8jiHi8Qx+e6VWxq
19UAn0sHf4w0g7Ek+WWUiJaetTGLoX2U
=dLWK
-----END PGP SIGNATURE-----

Martin Pool (mbp)
tags: added: conflicts merge remerge
Changed in bzr:
status: New → Confirmed
importance: Undecided → Low
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.