On 5 May 2011 10:32, Richard Sandiford richard.sandiford@linaro.org wrote:
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.
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