Subject: Re: [PATCH v2 5/7] add tests for rebasing merged history

From: Johannes Sixt <[email-masked]>
Date: Wed, 29 May 2013 12:33:45 +0200

Am 5/29/2013 8:39, schrieb Martin von Zweigbergk:
> +#       f
> +#      /
> +# a---b---c---g---h
> +#      \
> +#       d---G---i
> +#        \       \
> +#         e-------u
> +#
> +# uppercase = cherry-picked
> +# h = reverted g

> +test_expect_failure "rebase -p --onto in merged history does not lose patches in upstream" "
> +	reset_rebase &&
> +	git rebase -p --onto f h u &&
> +	test_cmp_rev f HEAD~3 &&
> +	test_revision_subjects 'd G i e u' HEAD~2 HEAD^2^ HEAD^2 HEAD^ HEAD
> +"

My expectations are different: When a patch is in upstream, then it is not
to be rebased, even --onto somewhere else than upstream.

But take this with a grain of salt, as I never encounter(ed) this use-case
in practice.

> +test_expect_success "rebase -p --onto in merged history drops patches in onto" "
> +	reset_rebase &&
> +	git rebase -p --onto h f u &&
> +	test_cmp_rev h HEAD~3 &&
> +	test_revision_subjects 'd i e u' HEAD~2 HEAD^2 HEAD^ HEAD
> +"

And this is just the opposite case, where I think the patch should be kept.

> +# a---b---c
> +#      \
> +#       d---e
> +#        \   \
> +#         n---r
> +#          \
> +#           o
> +#
> +# r = tree-same with n
> +# uppercace = cherry-picked

I do not see any upper-cased letters in this graph. ;)

> +test_expect_success "rebase -p re-creates empty internal merge commit" "
> +	reset_rebase &&
> +	git rebase -p c r &&
> +	test_revision_subjects 'c d e n r' HEAD~3 HEAD~2 HEAD^2 HEAD^ HEAD

Again, check c with test_cmp_rev.

-- Hannes