t / READMEon commit Merge branch 'jh/maint-do-not-track-non-branches' into maint (ac53196)
   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.  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; if a new function you added
 285   doesn't have any coverage, then you're probably doing something wrong,
 286   but having 100% coverage doesn't necessarily mean that you tested
 287   everything.
 288
 289   Tests that are likely to smoke out future regressions are better
 290   than tests that just inflate the coverage metrics.
 291
 292 - When a test checks for an absolute path that a git command generated,
 293   construct the expected value using $(pwd) rather than $PWD,
 294   $TEST_DIRECTORY, or $TRASH_DIRECTORY. It makes a difference on
 295   Windows, where the shell (MSYS bash) mangles absolute path names.
 296   For details, see the commit message of 4114156ae9.
 297
 298Don't:
 299
 300 - exit() within a <script> part.
 301
 302   The harness will catch this as a programming error of the test.
 303   Use test_done instead if you need to stop the tests early (see
 304   "Skipping tests" below).
 305
 306 - Break the TAP output
 307
 308   The raw output from your test may be interpreted by a TAP harness. TAP
 309   harnesses will ignore everything they don't know about, but don't step
 310   on their toes in these areas:
 311
 312   - Don't print lines like "$x..$y" where $x and $y are integers.
 313
 314   - Don't print lines that begin with "ok" or "not ok".
 315
 316   TAP harnesses expect a line that begins with either "ok" and "not
 317   ok" to signal a test passed or failed (and our harness already
 318   produces such lines), so your script shouldn't emit such lines to
 319   their output.
 320
 321   You can glean some further possible issues from the TAP grammar
 322   (see http://search.cpan.org/perldoc?TAP::Parser::Grammar#TAP_Grammar)
 323   but the best indication is to just run the tests with prove(1),
 324   it'll complain if anything is amiss.
 325
 326Keep in mind:
 327
 328 - Inside <script> part, the standard output and standard error
 329   streams are discarded, and the test harness only reports "ok" or
 330   "not ok" to the end user running the tests. Under --verbose, they
 331   are shown to help debugging the tests.
 332
 333
 334Skipping tests
 335--------------
 336
 337If you need to skip tests you should do so by using the three-arg form
 338of the test_* functions (see the "Test harness library" section
 339below), e.g.:
 340
 341    test_expect_success PERL 'I need Perl' "
 342        '$PERL_PATH' -e 'hlagh() if unf_unf()'
 343    "
 344
 345The advantage of skipping tests like this is that platforms that don't
 346have the PERL and other optional dependencies get an indication of how
 347many tests they're missing.
 348
 349If the test code is too hairy for that (i.e. does a lot of setup work
 350outside test assertions) you can also skip all remaining tests by
 351setting skip_all and immediately call test_done:
 352
 353        if ! test_have_prereq PERL
 354        then
 355            skip_all='skipping perl interface tests, perl not available'
 356            test_done
 357        fi
 358
 359The string you give to skip_all will be used as an explanation for why
 360the test was skipped.
 361
 362End with test_done
 363------------------
 364
 365Your script will be a sequence of tests, using helper functions
 366from the test harness library.  At the end of the script, call
 367'test_done'.
 368
 369
 370Test harness library
 371--------------------
 372
 373There are a handful helper functions defined in the test harness
 374library for your script to use.
 375
 376 - test_expect_success [<prereq>] <message> <script>
 377
 378   Usually takes two strings as parameter, and evaluates the
 379   <script>.  If it yields success, test is considered
 380   successful.  <message> should state what it is testing.
 381
 382   Example:
 383
 384        test_expect_success \
 385            'git-write-tree should be able to write an empty tree.' \
 386            'tree=$(git-write-tree)'
 387
 388   If you supply three parameters the first will be taken to be a
 389   prerequisite, see the test_set_prereq and test_have_prereq
 390   documentation below:
 391
 392        test_expect_success TTY 'git --paginate rev-list uses a pager' \
 393            ' ... '
 394
 395   You can also supply a comma-separated list of prerequisites, in the
 396   rare case where your test depends on more than one:
 397
 398        test_expect_success PERL,PYTHON 'yo dawg' \
 399            ' test $(perl -E 'print eval "1 +" . qx[python -c "print 2"]') == "4" '
 400
 401 - test_expect_failure [<prereq>] <message> <script>
 402
 403   This is NOT the opposite of test_expect_success, but is used
 404   to mark a test that demonstrates a known breakage.  Unlike
 405   the usual test_expect_success tests, which say "ok" on
 406   success and "FAIL" on failure, this will say "FIXED" on
 407   success and "still broken" on failure.  Failures from these
 408   tests won't cause -i (immediate) to stop.
 409
 410   Like test_expect_success this function can optionally use a three
 411   argument invocation with a prerequisite as the first argument.
 412
 413 - test_debug <script>
 414
 415   This takes a single argument, <script>, and evaluates it only
 416   when the test script is started with --debug command line
 417   argument.  This is primarily meant for use during the
 418   development of a new test script.
 419
 420 - test_done
 421
 422   Your test script must have test_done at the end.  Its purpose
 423   is to summarize successes and failures in the test script and
 424   exit with an appropriate error code.
 425
 426 - test_tick
 427
 428   Make commit and tag names consistent by setting the author and
 429   committer times to defined state.  Subsequent calls will
 430   advance the times by a fixed amount.
 431
 432 - test_commit <message> [<filename> [<contents>]]
 433
 434   Creates a commit with the given message, committing the given
 435   file with the given contents (default for both is to reuse the
 436   message string), and adds a tag (again reusing the message
 437   string as name).  Calls test_tick to make the SHA-1s
 438   reproducible.
 439
 440 - test_merge <message> <commit-or-tag>
 441
 442   Merges the given rev using the given message.  Like test_commit,
 443   creates a tag and calls test_tick before committing.
 444
 445 - test_set_prereq SOME_PREREQ
 446
 447   Set a test prerequisite to be used later with test_have_prereq. The
 448   test-lib will set some prerequisites for you, see the
 449   "Prerequisites" section below for a full list of these.
 450
 451   Others you can set yourself and use later with either
 452   test_have_prereq directly, or the three argument invocation of
 453   test_expect_success and test_expect_failure.
 454
 455 - test_have_prereq SOME PREREQ
 456
 457   Check if we have a prerequisite previously set with
 458   test_set_prereq. The most common use of this directly is to skip
 459   all the tests if we don't have some essential prerequisite:
 460
 461        if ! test_have_prereq PERL
 462        then
 463            skip_all='skipping perl interface tests, perl not available'
 464            test_done
 465        fi
 466
 467 - test_external [<prereq>] <message> <external> <script>
 468
 469   Execute a <script> with an <external> interpreter (like perl). This
 470   was added for tests like t9700-perl-git.sh which do most of their
 471   work in an external test script.
 472
 473        test_external \
 474            'GitwebCache::*FileCache*' \
 475            "$PERL_PATH" "$TEST_DIRECTORY"/t9503/test_cache_interface.pl
 476
 477   If the test is outputting its own TAP you should set the
 478   test_external_has_tap variable somewhere before calling the first
 479   test_external* function. See t9700-perl-git.sh for an example.
 480
 481        # The external test will outputs its own plan
 482        test_external_has_tap=1
 483
 484 - test_external_without_stderr [<prereq>] <message> <external> <script>
 485
 486   Like test_external but fail if there's any output on stderr,
 487   instead of checking the exit code.
 488
 489        test_external_without_stderr \
 490            'Perl API' \
 491            "$PERL_PATH" "$TEST_DIRECTORY"/t9700/test.pl
 492
 493 - test_expect_code <exit-code> <command>
 494
 495   Run a command and ensure that it exits with the given exit code.
 496   For example:
 497
 498        test_expect_success 'Merge with d/f conflicts' '
 499                test_expect_code 1 git merge "merge msg" B master
 500        '
 501
 502 - test_must_fail <git-command>
 503
 504   Run a git command and ensure it fails in a controlled way.  Use
 505   this instead of "! <git-command>".  When git-command dies due to a
 506   segfault, test_must_fail diagnoses it as an error; "! <git-command>"
 507   treats it as just another expected failure, which would let such a
 508   bug go unnoticed.
 509
 510 - test_might_fail <git-command>
 511
 512   Similar to test_must_fail, but tolerate success, too.  Use this
 513   instead of "<git-command> || :" to catch failures due to segv.
 514
 515 - test_cmp <expected> <actual>
 516
 517   Check whether the content of the <actual> file matches the
 518   <expected> file.  This behaves like "cmp" but produces more
 519   helpful output when the test is run with "-v" option.
 520
 521 - test_line_count (= | -lt | -ge | ...) <length> <file>
 522
 523   Check whether a file has the length it is expected to.
 524
 525 - test_path_is_file <file> [<diagnosis>]
 526   test_path_is_dir <dir> [<diagnosis>]
 527   test_path_is_missing <path> [<diagnosis>]
 528
 529   Check whether a file/directory exists or doesn't. <diagnosis> will
 530   be displayed if the test fails.
 531
 532 - test_when_finished <script>
 533
 534   Prepend <script> to a list of commands to run to clean up
 535   at the end of the current test.  If some clean-up command
 536   fails, the test will not pass.
 537
 538   Example:
 539
 540        test_expect_success 'branch pointing to non-commit' '
 541                git rev-parse HEAD^{tree} >.git/refs/heads/invalid &&
 542                test_when_finished "git update-ref -d refs/heads/invalid" &&
 543                ...
 544        '
 545
 546Prerequisites
 547-------------
 548
 549These are the prerequisites that the test library predefines with
 550test_have_prereq.
 551
 552See the prereq argument to the test_* functions in the "Test harness
 553library" section above and the "test_have_prereq" function for how to
 554use these, and "test_set_prereq" for how to define your own.
 555
 556 - PERL & PYTHON
 557
 558   Git wasn't compiled with NO_PERL=YesPlease or
 559   NO_PYTHON=YesPlease. Wrap any tests that need Perl or Python in
 560   these.
 561
 562 - POSIXPERM
 563
 564   The filesystem supports POSIX style permission bits.
 565
 566 - BSLASHPSPEC
 567
 568   Backslashes in pathspec are not directory separators. This is not
 569   set on Windows. See 6fd1106a for details.
 570
 571 - EXECKEEPSPID
 572
 573   The process retains the same pid across exec(2). See fb9a2bea for
 574   details.
 575
 576 - SYMLINKS
 577
 578   The filesystem we're on supports symbolic links. E.g. a FAT
 579   filesystem doesn't support these. See 704a3143 for details.
 580
 581 - SANITY
 582
 583   Test is not run by root user, and an attempt to write to an
 584   unwritable file is expected to fail correctly.
 585
 586Tips for Writing Tests
 587----------------------
 588
 589As with any programming projects, existing programs are the best
 590source of the information.  However, do _not_ emulate
 591t0000-basic.sh when writing your tests.  The test is special in
 592that it tries to validate the very core of GIT.  For example, it
 593knows that there will be 256 subdirectories under .git/objects/,
 594and it knows that the object ID of an empty tree is a certain
 59540-byte string.  This is deliberately done so in t0000-basic.sh
 596because the things the very basic core test tries to achieve is
 597to serve as a basis for people who are changing the GIT internal
 598drastically.  For these people, after making certain changes,
 599not seeing failures from the basic test _is_ a failure.  And
 600such drastic changes to the core GIT that even changes these
 601otherwise supposedly stable object IDs should be accompanied by
 602an update to t0000-basic.sh.
 603
 604However, other tests that simply rely on basic parts of the core
 605GIT working properly should not have that level of intimate
 606knowledge of the core GIT internals.  If all the test scripts
 607hardcoded the object IDs like t0000-basic.sh does, that defeats
 608the purpose of t0000-basic.sh, which is to isolate that level of
 609validation in one place.  Your test also ends up needing
 610updating when such a change to the internal happens, so do _not_
 611do it and leave the low level of validation to t0000-basic.sh.
 612
 613Test coverage
 614-------------
 615
 616You can use the coverage tests to find code paths that are not being
 617used or properly exercised yet.
 618
 619To do that, run the coverage target at the top-level (not in the t/
 620directory):
 621
 622    make coverage
 623
 624That'll compile Git with GCC's coverage arguments, and generate a test
 625report with gcov after the tests finish. Running the coverage tests
 626can take a while, since running the tests in parallel is incompatible
 627with GCC's coverage mode.
 628
 629After the tests have run you can generate a list of untested
 630functions:
 631
 632    make coverage-untested-functions
 633
 634You can also generate a detailed per-file HTML report using the
 635Devel::Cover module. To install it do:
 636
 637   # On Debian or Ubuntu:
 638   sudo aptitude install libdevel-cover-perl
 639
 640   # From the CPAN with cpanminus
 641   curl -L http://cpanmin.us | perl - --sudo --self-upgrade
 642   cpanm --sudo Devel::Cover
 643
 644Then, at the top-level:
 645
 646    make cover_db_html
 647
 648That'll generate a detailed cover report in the "cover_db_html"
 649directory, which you can then copy to a webserver, or inspect locally
 650in a browser.
 651
 652Smoke testing
 653-------------
 654
 655The Git test suite has support for smoke testing. Smoke testing is
 656when you submit the results of a test run to a central server for
 657analysis and aggregation.
 658
 659Running a smoke tester is an easy and valuable way of contributing to
 660Git development, particularly if you have access to an uncommon OS on
 661obscure hardware.
 662
 663After building Git you can generate a smoke report like this in the
 664"t" directory:
 665
 666    make clean smoke
 667
 668You can also pass arguments via the environment. This should make it
 669faster:
 670
 671    GIT_TEST_OPTS='--root=/dev/shm' TEST_JOBS=10 make clean smoke
 672
 673The "smoke" target will run the Git test suite with Perl's
 674"TAP::Harness" module, and package up the results in a .tar.gz archive
 675with "TAP::Harness::Archive". The former is included with Perl v5.10.1
 676or later, but you'll need to install the latter from the CPAN. See the
 677"Test coverage" section above for how you might do that.
 678
 679Once the "smoke" target finishes you'll see a message like this:
 680
 681    TAP Archive created at <path to git>/t/test-results/git-smoke.tar.gz
 682
 683To upload the smoke report you need to have curl(1) installed, then
 684do:
 685
 686    make smoke_report
 687
 688To upload the report anonymously. Hopefully that'll return something
 689like "Reported #7 added.".
 690
 691If you're going to be uploading reports frequently please request a
 692user account by E-Mailing gitsmoke@v.nix.is. Once you have a username
 693and password you'll be able to do:
 694
 695    SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> make smoke_report
 696
 697You can also add an additional comment to attach to the report, and/or
 698a comma separated list of tags:
 699
 700    SMOKE_USERNAME=<username> SMOKE_PASSWORD=<password> \
 701        SMOKE_COMMENT=<comment> SMOKE_TAGS=<tags> \
 702        make smoke_report
 703
 704Once the report is uploaded it'll be made available at
 705http://smoke.git.nix.is, here's an overview of Recent Smoke Reports
 706for Git:
 707
 708    http://smoke.git.nix.is/app/projects/smoke_reports/1
 709
 710The reports will also be mirrored to GitHub every few hours:
 711
 712    http://github.com/gitsmoke/smoke-reports
 713
 714The Smolder SQLite database is also mirrored and made available for
 715download:
 716
 717    http://github.com/gitsmoke/smoke-database
 718
 719Note that the database includes hashed (with crypt()) user passwords
 720and E-Mail addresses. Don't use a valuable password for the smoke
 721service if you have an account, or an E-Mail address you don't want to
 722be publicly known. The user accounts are just meant to be convenient
 723labels, they're not meant to be secure.