| 2009-05-01 13:22:54 |
William Grant |
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. |
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. |
|
