Reverting a file conflicted from a pull loses changes
Bug #370334 reported by
William Grant
This bug affects 3 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Confirmed
|
High
|
Unassigned | ||
| Breezy |
Triaged
|
Medium
|
Unassigned | ||
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.
Revision history for this message
| Matt Giuca (mgiuca) wrote | #1 |
| description: | updated |
Revision history for this message
| Aaron Bentley (abentley) wrote | #2 |
| Changed in bzr: | |
| importance: | Undecided → High |
| status: | New → Confirmed |
| tags: | added: treetransform |
| tags: | added: check-for-breezy |
| tags: | removed: check-for-breezy |
| Changed in brz: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
To post a comment you must log in.
The decision is made in bzrlib/
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.