1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-25 08:56:25 +02:00
git/t/interop
Ævar Arnfjörð Bjarmason 8df786d298 Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to it
We have various behavior that's shared across our Makefiles, or that
really should be (e.g. via defined templates). Let's create a
top-level "shared.mak" to house those sorts of things, and start by
adding the ".DELETE_ON_ERROR" flag to it.

See my own 7b76d6bf22 (Makefile: add and use the ".DELETE_ON_ERROR"
flag, 2021-06-29) and db10fc6c09 (doc: simplify Makefile using
.DELETE_ON_ERROR, 2021-05-21) for the addition and use of the
".DELETE_ON_ERROR" flag.

I.e. this changes the behavior of existing rules in the altered
Makefiles (except "Makefile" & "Documentation/Makefile"). I'm
confident that this is safe having read the relevant rules in those
Makfiles, and as the GNU make manual notes that it isn't the default
behavior is out of an abundance of backwards compatibility
caution. From edition 0.75 of its manual, covering GNU make 4.3:

    [Enabling '.DELETE_ON_ERROR' is] almost always what you want
    'make' to do, but it is not historical practice; so for
    compatibility, you must explicitly request it.

This doesn't introduce a bug by e.g. having this
".DELETE_ON_ERROR" flag only apply to this new shared.mak, Makefiles
have no such scoping semantics.

It does increase the danger that any Makefile without an explicit "The
default target of this Makefile is..." snippet to define the default
target as "all" could have its default rule changed if our new
shared.mak ever defines a "real" rule. In subsequent commits we'll be
careful not to do that, and such breakage would be obvious e.g. in the
case of "make -C t".

We might want to make that less fragile still (e.g. by using
".DEFAULT_GOAL" as noted in the preceding commit), but for now let's
simply include "shared.mak" without adding that boilerplate to all the
Makefiles that don't have it already. Most of those are already
exposed to that potential caveat e.g. due to including "config.mak*".

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-03 14:14:55 -08:00
..
.gitignore
Makefile
README
i0000-basic.sh
i5500-git-daemon.sh
i5700-protocol-transition.sh
interop-lib.sh

Git version interoperability tests
==================================

This directory has interoperability tests for git. Each script is
similar to the normal test scripts found in t/, but with the added twist
that two special versions of git, "git.a" and "git.b", are available in
the PATH. Individual tests can then check the interaction between the
two versions.

When you add a feature that handles backwards compatibility between git
versions, it's encouraged to add a test here to make sure it behaves as
you expect.


Running Tests
-------------

The easiest way to run tests is to say "make".  This runs all
the tests against their default versions.

You can run a single test like:

    $ ./i0000-basic.sh
    ok 1 - bare git is forbidden
    ok 2 - git.a version (v1.6.6.3)
    ok 3 - git.b version (v2.11.1)
    # passed all 3 test(s)
    1..3

Each test contains default versions to run against. You may override
these by setting `GIT_TEST_VERSION_A` and `GIT_TEST_VERSION_B` in the
environment. Note that not all combinations will give sensible outcomes
for all tests (e.g., a test checking for a specific old/new interaction
may want something "old" enough" and something "new" enough; see
individual tests for details).

Version names should be resolvable as revisions in the current
repository. They will be exported and built as needed using the
config.mak files found at the root of your working tree.

The exception is the special version "." which uses the currently-built
contents of your working tree.

You can set the following variables (in the environment or in your config.mak):

    GIT_INTEROP_MAKE_OPTS
	Options to pass to `make` when building a git version (e.g.,
	`-j8`).

You can also pass any command-line options taken by ordinary git tests (e.g.,
"-v").


Naming Tests
------------

The interop test files are named like:

	iNNNN-short-description.sh

where N is a decimal digit.  The same conventions for choosing NNNN as
for normal tests apply.


Writing Tests
-------------

An interop test script starts like a normal script, declaring a few
variables and then including interop-lib.sh (which includes test-lib.sh).
Besides test_description, you should also set the $VERSION_A and $VERSION_B
variables to give the default versions to test against. See t0000-basic.sh for
an example.

You can then use test_expect_success as usual, with a few differences:

  1. The special commands "git.a" and "git.b" correspond to the
     two versions.

  2. You cannot call a bare "git". This is to prevent accidents where
     you meant "git.a" or "git.b".

  3. The trash directory is _not_ a git repository by default. You
     should create one with the appropriate version of git.

At the end of the script, call test_done as usual.