Re: [PATCHv7 2/4] t7512-status-help.sh: better advices for git status

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

Kong Lucien <Lucien.Kong@ensimag.imag.fr> writes:

> +test_description='git status advices'
> +
> +. ./test-lib.sh
> +
> +. "$TEST_DIRECTORY"/lib-rebase.sh
> +
> +set_fake_editor
> +
> +test_expect_success 'status when conflicts unresolved' '
> +	test_commit init main.txt init &&
> +	git branch second_branch &&
> +	test_commit on_master main.txt on_master &&
> +	git checkout second_branch &&
> +	test_commit on_second_branch main.txt on_second_branch &&
> +	test_must_fail git merge master &&
> +	cat >expected <<-\EOF &&
> +	# On branch second_branch
> +	# You have unmerged paths.
> +	#   (fix conflicts and run "git commit")
> +	#
> +	# Unmerged paths:
> +	#   (use "git add/rm <file>..." as appropriate to mark resolution)
> +	#
> +	#	both modified:      main.txt
> +	#
> +	no changes added to commit (use "git add" and/or "git commit -a")
> +	EOF
> +	git status --untracked-files=no >actual &&
> +	test_cmp expected actual
> +'

OK.

> +test_expect_success 'status when conflicts resolved before commit' '
> +	test_when_finished "
> +		git commit -m "end_merge" &&
> +		git checkout master &&
> +		git branch -D second_branch &&
> +		echo >main.txt
> +	" &&

I do not think this is a good idea.  The previous one may have
failed before even reaching "git merge" that was supposed to fail,
or "git merge" may have succeeded by mistake.

If you are assuming that all tests succeed when we didn't introduce
any bug to Git, and when breakages happen the developer should only
look at the first breakage, then it is better not to pretend as if
you are prepared for some tests in the sequence to fail by giving a
clean slate to later tests.

For these two tests, I think it is much simpler and cleaner to
organize them by

 (1) have code to prepare two branches in the first test, tag the
     tip of second one, and assume this test won't break;

 (2) move the remainder of the first test, starting with the merge
     of master that is expected to fail, into a separate one; and

 (3) begin the third test (the second one in your patch) with:

 	git reset --hard $that_tag_you_added_to_the_tip_of_second &&
	test_must_fail git merge master &&

     so that it begins from the state the test expects it to begin
     in, even if the previous test somehow merged master cleanly by
     mistake.

> +test_expect_success 'status when rebase in progress before resolving conflicts' '
> +	test_commit one_rebase main.txt one &&
> +	test_commit two_rebase main.txt two &&
> +	test_commit three_rebase main.txt three &&
> +	test_must_fail git rebase HEAD^ --onto HEAD^^ &&
> +	cat >expected <<-\EOF &&
> +	# Not currently on any branch.
> +	# You are currently rebasing.
> +	#   (fix conflicts and then run "git rebase --continue")
> +	#   (use "git rebase --skip" to skip this patch)
> +	#   (use "git rebase --abort" to check out the original branch)
> +	#
> +	# Unmerged paths:
> +	#   (use "git reset HEAD <file>..." to unstage)
> +	#   (use "git add/rm <file>..." as appropriate to mark resolution)
> +	#
> +	#	both modified:      main.txt
> +	#
> +	no changes added to commit (use "git add" and/or "git commit -a")
> +	EOF
> +	git status --untracked-files=no >actual &&
> +	test_cmp expected actual
> +'
> +
> +
> +test_expect_success 'status when rebase in progress before rebase --continue' '
> +	test_when_finished "git rebase --abort" &&

Likewise.  If anything, "git rebase --abort" belongs to the previous
test that tried to run "git rebase".