[Python-Dev] Hg: inter-branch workflow (original) (raw)

R. David Murray rdmurray at bitdance.com
Sun Mar 20 05:06:01 CET 2011

On Thu, 17 Mar 2011 14:33:00 +0100, wrote:

On Thu, 17 Mar 2011 09:24:26 -0400 "R. David Murray" 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

More information about the Python-Dev mailing list