Reverting a file conflicted from a pull loses changes

Bug #370334 reported by William Grant on 2009-05-01
This bug affects 3 people
Affects Status Importance Assigned to Milestone

Bug Description

Reverting after a pull that causes conflicts is completely destructive - bzr revert's backup algorithm will only back the file up if it differs from the state created by the merge. This is fine for normal merges, as the initial working tree cannot differ from the tip. But a pull can happen with working tree changes.

It at first looked like an easy fix, but the state of the tree before the merge isn't recorded anywhere that I can see.

To reproduce:

 1) Create a new branch, A.
 2) Add and commit some file.
 3) Branch B from A.
 4) Alter the file in A and B in conflicting ways.
 5) Commit in A.
 6) Pull A into B, observing that a conflict occurs.
 7) Revert B.
 8) Cry, as Bazaar has eaten your changes without backing them up.

Matt Giuca (mgiuca) wrote :

The decision is made in bzrlib/, under the following line:
    if kind[0] == 'file' and (backups or kind[1] is None):

It needs to check if there were any uncommitted changes at the time of the merge, but it isn't clear that that information is recorded anywhere.

William Grant (wgrant) on 2009-05-01
description: updated
Aaron Bentley (abentley) wrote :

At robert's suggestion

Changed in bzr:
importance: Undecided → High
status: New → Confirmed
Vincent Ladeuil (vila) on 2010-11-19
tags: added: treetransform
Jelmer Vernooij (jelmer) on 2017-11-08
tags: added: check-for-breezy
Jelmer Vernooij (jelmer) on 2017-11-11
tags: removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers