Re: [PATCH] Interactive-rebase doesn't pick all children of "upstream"
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jun 5, 2011, 09:16 UTC
- Message-ID
- <4DEB495F.9080900@kdbg.org>
- In-Reply-To
- <1307251953-25116-1-git-send-email-andrew.kw.w@gmail.com>
Am 05.06.2011 07:32, schrieb Andrew Wong:
Show 17 quoted lines
> 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.
Show 6 quoted lines
> 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