(back to resolved)

For the record, this was not complete, see follow-up issue1561.

There, the failing test (test-rebase-collapse) mentioned in msg7626 was also 
fixed.

This should be fixed in, in main: http://www.selenic.com/hg/rev/45495d784ad6

Yes you're right.
As you can see test-rebase-collapse fails, it seems like it just forgets about
the previous merges.
I'll investigate further on this as soon as possible.

Putting your patch out there (that is, here, or on the devel list) would be a
good thing regardless.

I'm working on this but I still have a failing test (test-rebase-collapse)
without being able to understand why it fails.
If someone wants to help me with this issue I could upload the current patch
somewhere (e.g., here).

This is now one of a few things blocking a release. What can we do to fix this?

I've tried to wrap ancestor.ancestor when we actually merge and it seems to work.
The problem is define correctly which ancestor should be returned.
In most cases we want to return the parent of the node that's going to be
rebased, but what if that node had two parents (f in your second case)?

I've attached a file to describe the current behavior.
To sum up...
rebase e onto b means:
- update to b
- merge with e
- setparents(b, -1)
In the second step ancestor.ancestor returns correctly a.
For f onto e' it returns a, but should return e.

'virtual parent' here means that e is a parent of e' even though rebase erases
that information with setparents. So when we merge f, we need to somehow make
our ancestor code find e rather than a, probably by wrapping it.

mpm pasted this into the pastebin:

a-b
 \
  e-f

a-b-c-d-e'
 \   .-'
  \ /
   e-f

when we go to rebase f to f', we merge e' and f with a 'virtual parent' of e.

a-b
 \
  c-d-f-g
   \ /
    e

rebase c onto b...

a-b-c'-d'
 \    \  
  \    e'
   \
    c-d-f-g
     \ /
      e

f' = merge(d', f) with ancestor d

a-b-c'-d'-f'
 \    \  /
  \    e'
   \
    c-d-f-g
     \ /
      e

when we rebase g onto f', we have to remember that f is really an ancestor of f'
and should be the base for merge(f', g)

astratto, would this be easy to fix?

I frequently want to rebase a branch of multiple patches forward. This works
well if there are no conflicts. But if there are conflicts in the first rebased
change, all the subsequent rebasings require me to resolve the same conflict
over and over again, even if the subsequent changes don't touch the conflicting
file at all.

The same kind of workflow with hg qpush -m doesn't have this problem.

Testcase .sh script attached