Re: [PATCH] New test for rebase with preserve merges and squash

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 20, 2008, 23:46 UTC
Message-ID: <alpine.LSU.1.00.0803210040270.4124@racer.site>
In-Reply-To: <1206018070-3402-1-git-send-email-joerg@alea.gnuu.de>

Hi,

On Thu, 20 Mar 2008, Jörg Sommer wrote:

Show 35 quoted lines

> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 62e65d7..c849415 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -362,4 +362,56 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
>  
>  '
>  
> +test_expect_success 'squash and preserve merges' '
> +	test_tick &&
> +	git checkout -b squash-and-preserve-merges master &&
> +	echo A > file1 &&
> +	git commit -m SaPM-1 file1 &&
> +	echo B > file1 &&
> +	git commit -m SaPM-2 file1 &&
> +	git merge to-be-preserved &&
> +	echo C > file1 &&
> +	git commit -m SaPM-3 file1
> +'
> +
> +# This test should fail, because the prompt includes the commit from the
> +# merge not only the merge:
> +# -> pick 9604163 unrelated
> +#    pick 5ef0364 SaPM-1
> +#    pick 22aadcf SaPM-2
> +#    pick 828f7d8 Merge branch 'to-be-preserved' into squash-and-preserve-merges
> +#    pick 2a15a54 SaPM-3
> +test_expect_failure 'expect preserve merges shown not commits from merge' '
> +        EXPECT_COUNT=4 FAKE_LINES="1 2 squash 4 3" \
> +          git rebase -i -p --onto branch1 master ||
> +        { git rebase --abort;
> +          EXPECT_COUNT=5 FAKE_LINES="1 2 3 squash 5 4" \
> +          git rebase -i -p --onto branch1 master;
> +          false; }
> +'

I'm sorry, but I have to tell you: I do not like that style at all (for one, your expect_failure can succeed for all kind of reasons, the exit value of git rebase --abort is not even checked).

And I do not understand the message "expect preserve merges shown not commits from merge".

Which makes things kinda awkwardly hard for me.

So I have to guess that you think that in this case:

  B---D-E-F-G
 /   ,---'
A---C

a revision range B..G excludes C? Not so. "^B ^C G" would, but there is no way to specify this with a call to rebase.

So I find it quite logical that your test case fails.

Hth, Dscho