Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"

[Junio C Hamano <gitster@pobox.com>]

Andrew Wong <andrew.kw.w@gmail.com> writes:

> This patch fixes the inconsistency and bug by ensuring that all children
> of upstream are always picked.  This essentially reverts the commit:
>
>   d80d6bc (rebase-i-p: do not include non-first-parent commits touching UPSTREAM, 2008-10-15)

... whose commit log message mumbles about somebody's script but came with
no tests, so we will not know if this is breaking the other guy's workflow
while adding support to yours (Cc'ed Stephen Haberman who wrote the
previous one).

>  
> +test_expect_success '' '

There is no title to this test?

> +	(
> +	cd clone4 &&
> +	git fetch &&
> +	git rebase -p HEAD^2 &&
> +	test 1 = $(git rev-list --all --pretty=oneline | grep "Modify A" | wc -l) &&
> +	test 1 = $(git rev-list --all --pretty=oneline | grep "Modify B" | wc -l) &&
> +	test 1 = $(git rev-list --all --pretty=oneline | grep "Merge remote-tracking branch " | wc -l)
> +	)
> +'
> +
>  test_done

In general I think it is wrong to change behaviour depending on which
parent of a merge we are looking at (unless of course the user tells us
to, like "git log --first-parent"), so in that sense philosophically I
think the patch is going in the right direction, but I do worry about
potential regressions.