On Thu, 17 Mar 2011 14:33:00 +0100, wrote: > On Thu, 17 Mar 2011 09:24:26 -0400 > "R. David Murray" <rdmurray at bitdance.com> wrote: > > > > It would be great if rebase did work with share, that would make a > > push race basically a non-issue for me. > > rebase as well as strip destroy some history, meaning some of your > shared clones may end up having their working copy based on a > non-existent changeset. I'm not sure why rebase would be worse that > strip in that regard, though.
Well, it turns out that this completely doesn't work, though at first it appeared to (and so I pushed). I had a push race, so I did hg pull; hg rebase. Then I looked at the log, and I could (apparently) see my change sets on the top of the stack. So I pushed. Victor then asked why one of my commits deleted Tools/demo/README, and then the next commit restored it. What I was attempting to push was a doc change in 3.1 that I had then merged to 3.2 and default. What I saw when looking closer at the log (after Victor pointed it out) was that my merge commits had lost their parents. I thought that at worst a rebase would screw up my local history, but apparently I managed to push some sort of damaged history. The doc change only got applied to default, since that's the branch I happened to be in when I did the rebase. Needless to say, I'm avoiding rebase henceforth. I don't think this had anything to do with share, by the way, but rather the fact that I had merge commits before I did the rebase, and that rebase apparently operates on branches, not the repository has a whole. It would have been nice if rebase had refused to run given that there were merges, since it clearly doesn't work in that case. I'll backport the doc change tomorrow :( -- R. David Murray http://www.bitdance.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
