Re: [PATCH] Interactive-rebase doesn't pick all children of "upstream"

Am 05.06.2011 07:32, schrieb Andrew Wong:

Consider this graph:

        D---E    (topic, HEAD)
       /   /
  A---B---C      (master)
   \
    F            (topic2)

and the following three commands:
  1. git rebase -i A
  2. git rebase -i --onto F A
  3. git rebase -i B

Currently, (1) and (2) will pick B, D, C, and E onto A and F,
respectively.  However, (3) will only pick D and E onto B.  This
behavior of (3) is inconsistent with (1) and (2), and we cannot modify C
in the interactive-rebase.

I cannot reproduce your claims:

- (1) and (2) picks B,C,D top A and F, but not E because E is a merge.

- (3) picks C and D, but not E because E is a merge.

The current behavior also creates a bug if we do:
  4. git rebase -i C

In (4), E is never picked. And since interactive-rebase resets "HEAD" to
"onto" before picking any commits, D and E are lost after the
interactive-rebase.

(4) picks only D, because E is a merge. I don't understand what you mean
that "D and E are lost"; E is not picked in the first place, but D is in
the todo-list; how can D be lost?

BTW, rebase never picks merges by design. I don't see anything wrong so
far with the current behavior. Please explain!

-- Hannes