On 5 May 2011 10:32, Richard Sandiford <richard.sandif...@linaro.org> wrote: > 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.
Hi guys, all of the history is still preserved, as you can see by running 'bzr log -n0' on that branch. What has happened is that the last few revisions of trunk are now shown as being merged in to Richard's work, rather than his work being merged into trunk. Perhaps the main issue here is <https://bugs.launchpad.net/launchpad/+bug/777880> which is that the Launchpad message is a bit disturbing and offputting; also the bzr ui for doing the merge could be clearer. > 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: What I would probably recommend is: switch to a checkout of trunk, pull from the upstream trunk, then merge from your local branch, commit, and push. You can also use 'bzr bind lp:linaro-gcc' which will do the commit synchronously with updating the trunk branch and then there is no window it can get out of date. >> 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. I'd like to know more about the case where it's slow, because we have fixed up some of the other performance issues that were biting Linaro. Could you tell me more, or if you like file a bug at <http://pad.lv/fb/bzr-rebase> saying what you're running on what branches and what speed it is? > this is the right thing to do instead? rebase is a good option if you want to make the history look like you just did the work on top of the tip revision in the first place, but merging is fine too -- really it is up to the Linaro devs to decide how they want to run it. > Once again, I realise I should have asked this _before_ messing > things up, sorry. :-( You didn't really do anything wrong here. Sorry it was confusing. Martin _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
