Stefan Beller <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
