Re: [PATCHv2 6/6] t5543-atomic-push.sh: add basic tests for atomic pushes

Stefan Beller [off-list ref] writes:

+test_description='pushing to a repository using the atomic push option'
+
+. ./test-lib.sh
+
+D=`pwd`

$(pwd)?

+mk_repo_pair () {
+	rm -rf workbench upstream &&
+	test_create_repo upstream &&
+	test_create_repo workbench &&
+	(
+		cd upstream && git config receive.denyCurrentBranch warn
+	) &&

I was wondering how you would do this part after suggesting use of
test_create_repo, knowing very well that one of them was a bare one
;-).

We might want to extend test_create_repo to allow creating a bare
repository, but this is also OK.

+	(
+		cd workbench && git remote add up ../upstream
+	)
+}

+# refname, expected value, e.g.
+# test_ref_upstream refs/heads/master HEADS{0}
+test_ref_upstream () {
+	test "$#" == "2" # if this fails, we have a bug in this script.

This is not C; "test $# = 2" (notice a single equal sign).  And you
do not need dq-pair around these.

+	test "$(git -C upstream rev-parse --verify $1)" == "$2"
+}

Seeing that all callers of test_ref_upstream computes $2 as

	git -C workbench rev-parse --verify <something>

I have a feeling that

+	test_ref_upstream second second

would be easier for them to write than

+	test_ref_upstream second $(git -C workbench rev-parse --verify second)

That is

# refname in upstream and expected value from workbench
# E.g. "test_ref_upstream master HEAD" makes sure that HEAD in
# workbench matches the master branch in upstream repository.
test_ref_upstream () {
	test $# = 2 &&
        test "$(git -C upstream rev-parse --verify "$1")" == \
		"$(git -C workbench rev-parse --verify "$2")"
}

or something.  We may however want to do the usual

	test $# = 2 &&
	git -C upstream rev-parse --verify "$1" >expect &&
	git -C workbench rev-parse --verify "$2" >actual &&
        test_cmp expect actual

though.

On Tue, Dec 16, 2014 at 11:46 AM, Junio C Hamano [off-list ref] wrote:

Seeing that all callers of test_ref_upstream computes $2 as

        git -C workbench rev-parse --verify <something>

Only in the first tests, where this should be the case after push.
In the failure tests, we go with HEAD@{N} which needs to be computed
inside the workbench repo.

Alternatively we could check if the reflog of upstream has a certain
number of entries
which would indicate the push was not recorded (i.e. not performed?)

I think we should keep it similar to this one.