Andrew Stubbs ams@codesourcery.com writes:
On 05/05/11 08:43, Richard Sandiford wrote:
Anyway, the bzr help page seemed to suggest that merging in the new 4.6 revision was the Right Thing to do. I'm afraid that, once again, it felt so natural to resolve push conflicts this way that I didn't even question the assumption. I did the merge, and as expected, there was only one new commit: your change from yesterday. So I committed the merge and pushed again. bzr was happy this time. I didn't need any special options to push. Perhaps if I had, overdue alarm bells might finally have rung.
OK, so if I understand correctly, the merge was done correctly, but then the push didn't work. So far so good.
But then, merging from 4.6 to synchronize the branches somehow convinced bzr that it was ok to push without --overwrite, even though that would rewrite history.
Seems that way. FWIW, I thought when mecurial did this kind of thing, it preserved the history of both strands. Maybe git does too; I've never used git for a shared-push repo like this. I hadn't realised history could be lost.
But just to be clear, in the kind of situation where person A has pushed a new revision while person B was doing a merge, what should person B do when the push fails? Should they undo the local merge, pull, then merge again? Or is there a better way? Do you mean that:
BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command that works better in the case of diverged branches. It's slow as hell though.
this is the right thing to do instead?
Once again, I realise I should have asked this _before_ messing things up, sorry. :-(
Richard