On 5/29/07, Junio C Hamano <junkio@xxxxxxx> wrote:
Lars Hjemli <hjemli@xxxxxxxxx> writes: > +# create a submodule repository > +mkdir lib && cd lib > +git-init >/dev/null > +echo a >a && git-add a && git-commit -q -m "submodule commit 1" > +git-tag -a -m "rev-1" rev-1 > +rev1=$(git-rev-parse HEAD) > +cd .. > + > +# add submodule and other files to super repo > +echo a >a && echo z >z > +git-add a lib z && git-commit -q -m "super commit 1" > + > +# move submodule to another location, register repo url in .gitmodules > +mv lib .subrepo > +GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo We typically try to catch malfunction even while setting up the test case.
Ok
> +test_expect_success 'status is "missing"' \ > + 'git-submodule status | grep "^-$rev1"' > + > +# make sure 'init' will not overwrite a regular file > +touch lib > +test_expect_failure 'init fails when path is used by a file' \ > + 'git-submodule init' I am guilty for introducing "expect-failure", but it is usually a mistake to use it unless you are testing something very trivial. For example, for this case, you would want to make sure the command "git-submodule init" exits with non-zero status, but also you would want to make sure that it does not disturb the existing file "lib".
Would you prefer a patch on top of this version of the test-script or on top of the later patch which uses .git/config to store submodule url? -- larsh - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
