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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html