From: Johannes Sixt <j6t@kdbg.org>
Date: Sun, 05 Jun 2011 09:16:15 GMT
Subject: Re: [PATCH] Interactive-rebase doesn't pick all children of "upstream"
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:
> 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