Stefan Beller <sbel...@google.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html