d44a614ea32cf83915098e91ec7be603a13cb6d6
   1Core GIT Tests
   2==============
   3
   4This directory holds many test scripts for core GIT tools.  The
   5first part of this short document describes how to run the tests
   6and read their output.
   7
   8When fixing the tools or adding enhancements, you are strongly
   9encouraged to add tests in this directory to cover what you are
  10trying to fix or enhance.  The later part of this short document
  11describes how your test scripts should be organized.
  12
  13
  14Running Tests
  15-------------
  16
  17The easiest way to run tests is to say "make".  This runs all
  18the tests.
  19
  20    *** t0000-basic.sh ***
  21    ok 1 - .git/objects should be empty after git init in an empty repo.
  22    ok 2 - .git/objects should have 3 subdirectories.
  23    ok 3 - success is reported like this
  24    ...
  25    ok 43 - very long name in the index handled sanely
  26    # fixed 1 known breakage(s)
  27    # still have 1 known breakage(s)
  28    # passed all remaining 42 test(s)
  29    1..43
  30    *** t0001-init.sh ***
  31    ok 1 - plain
  32    ok 2 - plain with GIT_WORK_TREE
  33    ok 3 - plain bare
  34
  35Since the tests all output TAP (see http://testanything.org) they can
  36be run with any TAP harness. Here's an example of parallel testing
  37powered by a recent version of prove(1):
  38
  39    $ prove --timer --jobs 15 ./t[0-9]*.sh
  40    [19:17:33] ./t0005-signals.sh ................................... ok       36 ms
  41    [19:17:33] ./t0022-crlf-rename.sh ............................... ok       69 ms
  42    [19:17:33] ./t0024-crlf-archive.sh .............................. ok      154 ms
  43    [19:17:33] ./t0004-unwritable.sh ................................ ok      289 ms
  44    [19:17:33] ./t0002-gitfile.sh ................................... ok      480 ms
  45    ===(     102;0  25/?  6/?  5/?  16/?  1/?  4/?  2/?  1/?  3/?  1... )===
  46
  47prove and other harnesses come with a lot of useful options. The
  48--state option in particular is very useful:
  49
  50    # Repeat until no more failures
  51    $ prove -j 15 --state=failed,save ./t[0-9]*.sh
  52
  53You can give DEFAULT_TEST_TARGET=prove on the make command (or define it
  54in config.mak) to cause "make test" to run tests under prove.
  55GIT_PROVE_OPTS can be used to pass additional options, e.g.
  56
  57    $ make DEFAULT_TEST_TARGET=prove GIT_PROVE_OPTS='--timer --jobs 16' test
  58
  59You can also run each test individually from command line, like this:
  60
  61    $ sh ./t3010-ls-files-killed-modified.sh
  62    ok 1 - git update-index --add to add various paths.
  63    ok 2 - git ls-files -k to show killed files.
  64    ok 3 - validate git ls-files -k output.
  65    ok 4 - git ls-files -m to show modified files.
  66    ok 5 - validate git ls-files -m output.
  67    # passed all 5 test(s)
  68    1..5
  69
  70You can pass --verbose (or -v), --debug (or -d), and --immediate
  71(or -i) command line argument to the test, or by setting GIT_TEST_OPTS
  72appropriately before running "make".
  73
  74--verbose::
  75        This makes the test more verbose.  Specifically, the
  76        command being run and their output if any are also
  77        output.
  78
  79--debug::
  80        This may help the person who is developing a new test.
  81        It causes the command defined with test_debug to run.
  82
  83--immediate::
  84        This causes the test to immediately exit upon the first
  85        failed test.
  86
  87--long-tests::
  88        This causes additional long-running tests to be run (where
  89        available), for more exhaustive testing.
  90
  91--valgrind::
  92        Execute all Git binaries with valgrind and exit with status
  93        126 on errors (just like regular tests, this will only stop
  94        the test script when running under -i).  Valgrind errors
  95        go to stderr, so you might want to pass the -v option, too.
  96
  97        Since it makes no sense to run the tests with --valgrind and
  98        not see any output, this option implies --verbose.  For
  99        convenience, it also implies --tee.
 100
 101        Note that valgrind is run with the option --leak-check=no,
 102        as the git process is short-lived and some errors are not
 103        interesting. In order to run a single command under the same
 104        conditions manually, you should set GIT_VALGRIND to point to
 105        the 't/valgrind/' directory and use the commands under
 106        't/valgrind/bin/'.
 107
 108--tee::
 109        In addition to printing the test output to the terminal,
 110        write it to files named 't/test-results/$TEST_NAME.out'.
 111        As the names depend on the tests' file names, it is safe to
 112        run the tests with this option in parallel.
 113
 114--with-dashes::
 115        By default tests are run without dashed forms of
 116        commands (like git-commit) in the PATH (it only uses
 117        wrappers from ../bin-wrappers).  Use this option to include
 118        the build directory (..) in the PATH, which contains all
 119        the dashed forms of commands.  This option is currently
 120        implied by other options like --valgrind and
 121        GIT_TEST_INSTALLED.
 122
 123--root=<directory>::
 124        Create "trash" directories used to store all temporary data during
 125        testing under <directory>, instead of the t/ directory.
 126        Using this option with a RAM-based filesystem (such as tmpfs)
 127        can massively speed up the test suite.
 128
 129You can also set the GIT_TEST_INSTALLED environment variable to
 130the bindir of an existing git installation to test that installation.
 131You still need to have built this git sandbox, from which various
 132test-* support programs, templates, and perl libraries are used.
 133If your installed git is incomplete, it will silently test parts of
 134your built version instead.
 135
 136When using GIT_TEST_INSTALLED, you can also set GIT_TEST_EXEC_PATH to
 137override the location of the dashed-form subcommands (what
 138GIT_EXEC_PATH would be used for during normal operation).
 139GIT_TEST_EXEC_PATH defaults to `$GIT_TEST_INSTALLED/git --exec-path`.
 140
 141
 142Skipping Tests
 143--------------
 144
 145In some environments, certain tests have no way of succeeding
 146due to platform limitation, such as lack of 'unzip' program, or
 147filesystem that do not allow arbitrary sequence of non-NUL bytes
 148as pathnames.
 149
 150You should be able to say something like
 151
 152    $ GIT_SKIP_TESTS=t9200.8 sh ./t9200-git-cvsexport-commit.sh
 153
 154and even:
 155
 156    $ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make
 157
 158to omit such tests.  The value of the environment variable is a
 159SP separated list of patterns that tells which tests to skip,
 160and either can match the "t[0-9]{4}" part to skip the whole
 161test, or t[0-9]{4} followed by ".$number" to say which
 162particular test to skip.
 163
 164Note that some tests in the existing test suite rely on previous
 165test item, so you cannot arbitrarily disable one and expect the
 166remainder of test to check what the test originally was intended
 167to check.
 168
 169
 170Naming Tests
 171------------
 172
 173The test files are named as:
 174
 175        tNNNN-commandname-details.sh
 176
 177where N is a decimal digit.
 178
 179First digit tells the family:
 180
 181        0 - the absolute basics and global stuff
 182        1 - the basic commands concerning database
 183        2 - the basic commands concerning the working tree
 184        3 - the other basic commands (e.g. ls-files)
 185        4 - the diff commands
 186        5 - the pull and exporting commands
 187        6 - the revision tree commands (even e.g. merge-base)
 188        7 - the porcelainish commands concerning the working tree
 189        8 - the porcelainish commands concerning forensics
 190        9 - the git tools
 191
 192Second digit tells the particular command we are testing.
 193
 194Third digit (optionally) tells the particular switch or group of switches
 195we are testing.
 196
 197If you create files under t/ directory (i.e. here) that is not
 198the top-level test script, never name the file to match the above
 199pattern.  The Makefile here considers all such files as the
 200top-level test script and tries to run all of them.  A care is
 201especially needed if you are creating a common test library
 202file, similar to test-lib.sh, because such a library file may
 203not be suitable for standalone execution.
 204
 205
 206Writing Tests
 207-------------
 208
 209The test script is written as a shell script.  It should start
 210with the standard "#!/bin/sh" with copyright notices, and an
 211assignment to variable 'test_description', like this:
 212
 213        #!/bin/sh
 214        #
 215        # Copyright (c) 2005 Junio C Hamano
 216        #
 217
 218        test_description='xxx test (option --frotz)
 219
 220        This test registers the following structure in the cache
 221        and tries to run git-ls-files with option --frotz.'
 222
 223
 224Source 'test-lib.sh'
 225--------------------
 226
 227After assigning test_description, the test script should source
 228test-lib.sh like this:
 229
 230        . ./test-lib.sh
 231
 232This test harness library does the following things:
 233
 234 - If the script is invoked with command line argument --help
 235   (or -h), it shows the test_description and exits.
 236
 237 - Creates an empty test directory with an empty .git/objects database
 238   and chdir(2) into it.  This directory is 't/trash
 239   directory.$test_name_without_dotsh', with t/ subject to change by
 240   the --root option documented above.
 241
 242 - Defines standard test helper functions for your scripts to
 243   use.  These functions are designed to make all scripts behave
 244   consistently when command line arguments --verbose (or -v),
 245   --debug (or -d), and --immediate (or -i) is given.
 246
 247Do's, don'ts & things to keep in mind
 248-------------------------------------
 249
 250Here are a few examples of things you probably should and shouldn't do
 251when writing tests.
 252
 253Do:
 254
 255 - Put all code inside test_expect_success and other assertions.
 256
 257   Even code that isn't a test per se, but merely some setup code
 258   should be inside a test assertion.
 259
 260 - Chain your test assertions
 261
 262   Write test code like this:
 263
 264        git merge foo &&
 265        git push bar &&
 266        test ...
 267
 268   Instead of:
 269
 270        git merge hla
 271        git push gh
 272        test ...
 273
 274   That way all of the commands in your tests will succeed or fail. If
 275   you must ignore the return value of something, consider using a
 276   helper function (e.g. use sane_unset instead of unset, in order
 277   to avoid unportable return value for unsetting a variable that was
 278   already unset), or prepending the command with test_might_fail or
 279   test_must_fail.
 280
 281 - Check the test coverage for your tests. See the "Test coverage"
 282   below.
 283
 284   Don't blindly follow test coverage metrics, they're a good way to
 285   spot if you've missed something. If a new function you added
 286   doesn't have any coverage you're probably doing something wrong,
 287   but having 100% coverage doesn't necessarily mean that you tested
 288   everything.
 289
 290   Tests that are likely to smoke out future regressions are better
 291   than tests that just inflate the coverage metrics.
 292
 293 - When a test checks for an absolute path that a git command generated,
 294   construct the expected value using $(pwd) rather than $PWD,
 295   $TEST_DIRECTORY, or $TRASH_DIRECTORY. It makes a difference on
 296   Windows, where the shell (MSYS bash) mangles absolute path names.
 297   For details, see the commit message of 4114156ae9.
 298
 299Don't:
 300
 301 - exit() within a <script> part.
 302
 303   The harness will catch this as a programming error of the test.
 304   Use test_done instead if you need to stop the tests early (see
 305   "Skipping tests" below).
 306
 307 - Break the TAP output
 308
 309   The raw output from your test may be interpreted by a TAP harness. TAP
 310   harnesses will ignore everything they don't know about, but don't step
 311   on their toes in these areas:
 312
 313   - Don't print lines like "$x..$y" where $x and $y are integers.
 314
 315   - Don't print lines that begin with "ok" or "not ok".
 316
 317   TAP harnesses expect a line that begins with either "ok" and "not
 318   ok" to signal a test passed or failed (and our harness already
 319   produces such lines), so your script shouldn't emit such lines to
 320   their output.
 321
 322   You can glean some further possible issues from the TAP grammar
 323   (see http://search.cpan.org/perldoc?TAP::Parser::Grammar#TAP_Grammar)
 324   but the best indication is to just run the tests with prove(1),
 325   it'll complain if anything is amiss.
 326
 327Keep in mind:
 328
 329 - Inside <script> part, the standard output and standard error
 330   streams are discarded, and the test harness only reports "ok" or
 331   "not ok" to the end user running the tests. Under --verbose, they
 332   are shown to help debugging the tests.
 333
 334
 335Skipping tests
 336--------------
 337
 338If you need to skip tests you should do so by using the three-arg form
 339of the test_* functions (see the "Test harness library" section
 340below), e.g.:
 341
 342    test_expect_success PERL 'I need Perl' "
 343        '$PERL_PATH' -e 'hlagh() if unf_unf()'
 344    "
 345
 346The advantage of skipping tests like this is that platforms that don't
 347have the PERL and other optional dependencies get an indication of how
 348many tests they're missing.
 349
 350If the test code is too hairy for that (i.e. does a lot of setup work
 351outside test assertions) you can also skip all remaining tests by
 352setting skip_all and immediately call test_done:
 353
 354        if ! test_have_prereq PERL
 355        then
 356            skip_all='skipping perl interface tests, perl not available'
 357            test_done
 358        fi
 359
 360The string you give to skip_all will be used as an explanation for why
 361the test was skipped.
 362
 363End with test_done
 364------------------
 365
 366Your script will be a sequence of tests, using helper functions
 367from the test harness library.  At the end of the script, call
 368'test_done'.
 369
 370
 371Test harness library
 372--------------------
 373
 374There are a handful helper functions defined in the test harness
 375library for your script to use.
 376
 377 - test_expect_success [<prereq>] <message> <script>
 378
 379   Usually takes two strings as parameter, and evaluates the
 380   <script>.  If it yields success, test is considered
 381   successful.  <message> should state what it is testing.
 382
 383   Example:
 384
 385        test_expect_success \
 386            'git-write-tree should be able to write an empty tree.' \
 387            'tree=$(git-write-tree)'
 388
 389   If you supply three parameters the first will be taken to be a
 390   prerequisite, see the test_set_prereq and test_have_prereq
 391   documentation below:
 392
 393        test_expect_success TTY 'git --paginate rev-list uses a pager' \
 394            ' ... '
 395
 396   You can also supply a comma-separated list of prerequisites, in the
 397   rare case where your test depends on more than one:
 398
 399        test_expect_success PERL,PYTHON 'yo dawg' \
 400            ' test $(perl -E 'print eval "1 +" . qx[python -c "print 2"]') == "4" '
 401
 402 - test_expect_failure [<prereq>] <message> <script>
 403
 404   This is NOT the opposite of test_expect_success, but is used
 405   to mark a test that demonstrates a known breakage.  Unlike
 406   the usual test_expect_success tests, which say "ok" on
 407   success and "FAIL" on failure, this will say "FIXED" on
 408   success and "still broken" on failure.  Failures from these
 409   tests won't cause -i (immediate) to stop.
 410
 411   Like test_expect_success this function can optionally use a three
 412   argument invocation with a prerequisite as the first argument.
 413
 414 - test_debug <script>
 415
 416   This takes a single argument, <script>, and evaluates it only
 417   when the test script is started with --debug command line
 418   argument.  This is primarily meant for use during the
 419   development of a new test script.
 420
 421 - test_done
 422
 423   Your test script must have test_done at the end.  Its purpose
 424   is to summarize successes and failures in the test script and
 425   exit with an appropriate error code.
 426
 427 - test_tick
 428
 429   Make commit and tag names consistent by setting the author and
 430   committer times to defined stated.  Subsequent calls will
 431   advance the times by a fixed amount.
 432
 433 - test_commit <message> [<filename> [<contents>]]
 434
 435   Creates a commit with the given message, committing the given
 436   file with the given contents (default for both is to reuse the
 437   message string), and adds a tag (again reusing the message
 438   string as name).  Calls test_tick to make the SHA-1s
 439   reproducible.
 440
 441 - test_merge <message> <commit-or-tag>
 442
 443   Merges the given rev using the given message.  Like test_commit,
 444   creates a tag and calls test_tick before committing.
 445
 446 - test_set_prereq SOME_PREREQ
 447
 448   Set a test prerequisite to be used later with test_have_prereq. The
 449   test-lib will set some prerequisites for you, see the
 450   "Prerequisites" section below for a full list of these.
 451
 452   Others you can set yourself and use later with either
 453   test_have_prereq directly, or the three argument invocation of
 454   test_expect_success and test_expect_failure.
 455
 456 - test_have_prereq SOME PREREQ
 457
 458   Check if we have a prerequisite previously set with
 459   test_set_prereq. The most common use of this directly is to skip
 460   all the tests if we don't have some essential prerequisite:
 461
 462        if ! test_have_prereq PERL
 463        then
 464            skip_all='skipping perl interface tests, perl not available'
 465            test_done
 466        fi
 467
 468 - test_external [<prereq>] <message> <external> <script>
 469
 470   Execute a <script> with an <external> interpreter (like perl). This
 471   was added for tests like t9700-perl-git.sh which do most of their
 472   work in an external test script.
 473
 474        test_external \
 475            'GitwebCache::*FileCache*' \
 476            "$PERL_PATH" "$TEST_DIRECTORY"/t9503/test_cache_interface.pl
 477
 478   If the test is outputting its own TAP you should set the
 479   test_external_has_tap variable somewhere before calling the first
 480   test_external* function. See t9700-perl-git.sh for an example.
 481
 482        # The external test will outputs its own plan
 483        test_external_has_tap=1
 484
 485 - test_external_without_stderr [<prereq>] <message> <external> <script>
 486
 487   Like test_external but fail if there's any output on stderr,
 488   instead of checking the exit code.
 489
 490        test_external_without_stderr \
 491            'Perl API' \
 492            "$PERL_PATH" "$TEST_DIRECTORY"/t9700/test.pl
 493
 494 - test_expect_code <exit-code> <command>
 495
 496   Run a command and ensure that it exits with the given exit code.
 497   For example:
 498
 499        test_expect_success 'Merge with d/f conflicts' '
 500                test_expect_code 1 git merge "merge msg" B master
 501        '
 502
 503 - test_must_fail <git-command>
 504
 505   Run a git command and ensure it fails in a controlled way.  Use
 506   this instead of "! <git-command>".  When git-command dies due to a
 507   segfault, test_must_fail diagnoses it as an error; "! <git-command>"
 508   treats it as just another expected failure, which would let such a
 509   bug go unnoticed.
 510
 511 - test_might_fail <git-command>
 512
 513   Similar to test_must_fail, but tolerate success, too.  Use this
 514   instead of "<git-command> || :" to catch failures due to segv.
 515
 516 - test_cmp <expected> <actual>
 517
 518   Check whether the content of the <actual> file matches the
 519   <expected> file.  This behaves like "cmp" but produces more
 520   helpful output when the test is run with "-v" option.
 521
 522 - test_line_count (= | -lt | -ge | ...) <length> <file>
 523
 524   Check whether a file has the length it is expected to.
 525
 526 - test_path_is_file <file> [<diagnosis>]
 527   test_path_is_dir <dir> [<diagnosis>]
 528   test_path_is_missing <path> [<diagnosis>]
 529
 530   Check whether a file/directory exists or doesn't. <diagnosis> will
 531   be displayed if the test fails.
 532
 533 - test_when_finished <script>
 534
 535   Prepend <script> to a list of commands to run to clean up
 536   at the end of the current test.  If some clean-up command
 537   fails, the test will not pass.
 538
 539   Example:
 540
 541        test_expect_success 'branch pointing to non-commit' '
 542                git rev-parse HEAD^{tree} >.git/refs/heads/invalid &&
 543                test_when_finished "git update-ref -d refs/heads/invalid" &&
 544                ...
 545        '
 546
 547Prerequisites
 548-------------
 549
 550These are the prerequisites that the test library predefines with
 551test_have_prereq.
 552
 553See the prereq argument to the test_* functions in the "Test harness
 554library" section above and the "test_have_prereq" function for how to
 555use these, and "test_set_prereq" for how to define your own.
 556
 557 - PERL & PYTHON
 558
 559   Git wasn't compiled with NO_PERL=YesPlease or
 560   NO_PYTHON=YesPlease. Wrap any tests that need Perl or Python in
 561   these.
 562
 563 - POSIXPERM
 564
 565   The filesystem supports POSIX style permission bits.
 566
 567 - BSLASHPSPEC
 568
 569   Backslashes in pathspec are not directory separators. This is not
 570   set on Windows. See 6fd1106a for details.
 571
 572 - EXECKEEPSPID
 573
 574   The process retains the same pid across exec(2). See fb9a2bea for
 575   details.
 576
 577 - SYMLINKS
 578
 579   The filesystem we're on supports symbolic links. E.g. a FAT
 580   filesystem doesn't support these. See 704a3143 for details.
 581
 582 - SANITY
 583
 584   Test is not run by root user, and an attempt to write to an
 585   unwritable file is expected to fail correctly.
 586
 587Tips for Writing Tests
 588----------------------
 589
 590As with any programming projects, existing programs are the best
 591source of the information.  However, do _not_ emulate
 592t0000-basic.sh when writing your tests.  The test is special in
 593that it tries to validate the very core of GIT.  For example, it
 594knows that there will be 256 subdirectories under .git/objects/,
 595and it knows that the object ID of an empty tree is a certain
 59640-byte string.  This is deliberately done so in t0000-basic.sh
 597because the things the very basic core test tries to achieve is
 598to serve as a basis for people who are changing the GIT internal
 599drastically.  For these people, after making certain changes,
 600not seeing failures from the basic test _is_ a failure.  And
 601such drastic changes to the core GIT that even changes these
 602otherwise supposedly stable object IDs should be accompanied by
 603an update to t0000-basic.sh.
 604
 605However, other tests that simply rely on basic parts of the core
 606GIT working properly should not have that level of intimate
 607knowledge of the core GIT internals.  If all the test scripts
 608hardcoded the object IDs like t0000-basic.sh does, that defeats
 609the purpose of t0000-basic.sh, which is to isolate that level of
 610validation in one place.  Your test also ends up needing
 611updating when such a change to the internal happens, so do _not_
 612do it and leave the low level of validation to t0000-basic.sh.
 613
 614Test coverage
 615-------------
 616
 617You can use the coverage tests to find code paths that are not being
 618used or properly exercised yet.
 619
 620To do that, run the coverage target at the top-level (not in the t/
 621directory):
 622
 623    make coverage
 624
 625That'll compile Git with GCC's coverage arguments, and generate a test
 626report with gcov after the tests finish. Running the coverage tests
 627can take a while, since running the tests in parallel is incompatible
 628with GCC's coverage mode.
 629
 630After the tests have run you can generate a list of untested
 631functions:
 632
 633    make coverage-untested-functions
 634
 635You can also generate a detailed per-file HTML report using the
 636Devel::Cover module. To install it do:
 637
 638   # On Debian or Ubuntu:
 639   sudo aptitude install libdevel-cover-perl
 640
 641   # From the CPAN with cpanminus
 642   curl -L http://cpanmin.us | perl - --sudo --self-upgrade
 643   cpanm --sudo Devel::Cover
 644
 645Then, at the top-level:
 646
 647    make cover_db_html
 648
 649That'll generate a detailed cover report in the "cover_db_html"
 650directory, which you can then copy to a webserver, or inspect locally
 651in a browser.
 652
 653Smoke testing
 654-------------
 655
 656The Git test suite has support for smoke testing. Smoke testing is
 657when you submit the results of a test run to a central server for
 658analysis and aggregation.
 659
 660Running a smoke tester is an easy and valuable way of contributing to
 661Git development, particularly if you have access to an uncommon OS on
 662obscure hardware.
 663
 664After building Git you can generate a smoke report like this in the
 665"t" directory:
 666
 667    make clean smoke
 668
 669You can also pass arguments via the environment. This should make it
 670faster:
 671
 672    GIT_TEST_OPTS='--root=/dev/shm' TEST_JOBS=10 make clean smoke
 673
 674The "smoke" target will run the Git test suite with Perl's
 675"TAP::Harness" module, and package up the results in a .tar.gz archive
 676with "TAP::Harness::Archive". The former is included with Perl v5.10.1
 677or later, but you'll need to install the latter from the CPAN. See the
 678"Test coverage" section above for how you might do that.
 679
 680Once the "smoke" target finishes you'll see a message like this:
 681
 682    TAP Archive created at <path to git>/t/test-results/git-smoke.tar.gz
 683
 684To upload the smoke report you need to have curl(1) installed, then
 685do:
 686
 687    make smoke_report
 688
 689To upload the report anonymously. Hopefully that'll return something
 690like "Reported #7 added.".
 691
 692If you're going to be uploading reports frequently please request a
 693user account by E-Mailing gitsmoke@v.nix.is. Once you have a username
 694and password you'll be able to do:
 695
 696    SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> make smoke_report
 697
 698You can also add an additional comment to attach to the report, and/or
 699a comma separated list of tags:
 700
 701    SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> \
 702        SMOKE_COMMENT=<comment> SMOKE_TAGS=<tags> \
 703        make smoke_report
 704
 705Once the report is uploaded it'll be made available at
 706http://smoke.git.nix.is, here's an overview of Recent Smoke Reports
 707for Git:
 708
 709    http://smoke.git.nix.is/app/projects/smoke_reports/1
 710
 711The reports will also be mirrored to GitHub every few hours:
 712
 713    http://github.com/gitsmoke/smoke-reports
 714
 715The Smolder SQLite database is also mirrored and made available for
 716download:
 717
 718    http://github.com/gitsmoke/smoke-database
 719
 720Note that the database includes hashed (with crypt()) user passwords
 721and E-Mail addresses. Don't use a valuable password for the smoke
 722service if you have an account, or an E-Mail address you don't want to
 723be publicly known. The user accounts are just meant to be convenient
 724labels, they're not meant to be secure.