Andrew Stubbs <a...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
