[PATCH v1 1/1] tests: add Git submodule version consistency test

John Keeping john at keeping.me.uk
Tue Mar 19 21:33:33 CET 2013


On Tue, Mar 19, 2013 at 09:22:06PM +0100, Ferry Huberts wrote:
> 
> 
> On 19/03/13 21:00, John Keeping wrote:
> > Subject: [PATCH] tests: check that Git version are in sync
> >
> > This ensures that the Git version pointed at by the submodule is the
> > same as the one that will be fetched using "make get-git".
> >
> > Suggested-by: Ferry Huberts <ferry.huberts at pelagic.nl>
> > Signed-off-by: John Keeping <john at keeping.me.uk>
> > ---
> > This is an enhanced version of what I posted earlier, which now checks
> > that the correct Git version is available even if "make get-git" has
> > been used to fetch it, by examining Git's GIT-VERSION-FILE.
> 
> I don't agree with that.
> IMHO we should check that the submodule SHA as stored in the repository 
> matches the version specified in the Makefile.
> 
> Now you check 2 versions that might be 'dirty' against each other; the 
> version in the Makefile to whatever someone has put in the git 
> directory. That can easily pass testing locally but fail testing once 
> committed (commit dirty Makefile but forget to adjust submodule SHA to 
> match 'development' git directory unpacked from a random git tar download).

The test using GIT-VERSION-FILE will catch this, that's generated during
the Git build process to match precisely what is built (including a
dirty flag).

> I'd prefer a situation in which we make sure that we test as close to a 
> clean checkout as possible, which means that we should use committed 
> state (when possible).

The second check is doing that (or close to it, we're checking staged
state rather than committed state, which is better in the case that
you've got a commit ready and want to sanity check it before typing "git
commit").

I think the combination of these two tests gives what you want, the
GIT-VERSION-FILE tests that the version of Git being used to build CGit
matches the Makefile and the "git ls-files --stage -- git" test checks
that what's in the index matches.  We could change that to "git ls-tree
HEAD -- git" but I think that is unnecessarily annoying for people
trying out new Git versions.

> >
> > I also changed the submodule test to check the version of the submodule
> > in the index rather than whatever happens to be checked out.  I think
> > this is a more sensible test for people who are experimenting with
> > different Git versions.
> >
> >   tests/t0001-validate-git-versions.sh | 36 ++++++++++++++++++++++++++++++++++++
> >   1 file changed, 36 insertions(+)
> >   create mode 100755 tests/t0001-validate-git-versions.sh
> >
> > diff --git a/tests/t0001-validate-git-versions.sh b/tests/t0001-validate-git-versions.sh
> > new file mode 100755
> > index 0000000..3378358
> > --- /dev/null
> > +++ b/tests/t0001-validate-git-versions.sh
> > @@ -0,0 +1,36 @@
> > +#!/bin/sh
> > +
> > +. ./setup.sh
> > +
> > +prepare_tests 'Check Git version is correct'
> > +
> > +run_test 'extract Git version from Makefile' '
> > +	sed -n -e "/^GIT_VER[ 	]*=/ {
> > +		s/^GIT_VER[ 	]*=[ 	]*//
> > +		p
> > +	}" ../Makefile >trash/makefile_version
> > +'
> > +
> > +run_test 'test Git version matches Makefile' '
> > +	( cat ../git/GIT-VERSION-FILE || echo "No GIT-VERSION-FILE" ) |
> > +	sed -e "s/GIT_VERSION[ 	]*=[ 	]*//" >trash/git_version &&
> > +	diff -u trash/git_version trash/makefile_version
> > +'
> > +
> > +run_test 'test submodule version matches Makefile' '
> > +	if ! test -e ../git/.git
> > +	then
> > +		echo "git/ is not a Git repository" >&2
> > +	else
> > +		(
> > +			cd .. &&
> > +			sm_sha1=$(git ls-files --stage -- git |
> > +				sed -e "s/^[0-9]* \\([0-9a-f]*\\) [0-9]	.*$/\\1/") &&
> > +			cd git &&
> > +			git describe --match "v[0-9]*" $sm_sha1
> > +		) | sed -e "s/^v//" >trash/sm_version &&
> > +		diff -u trash/sm_version trash/makefile_version
> > +	fi
> > +'
> > +
> > +tests_done
> >
> 
> -- 
> Ferry Huberts
> 
> _______________________________________________
> cgit mailing list
> cgit at hjemli.net
> http://hjemli.net/mailman/listinfo/cgit




More information about the CGit mailing list