Merge branch 'bp/name-hash-dirname-fix'
[gitweb.git] / t / perf / README
index 8848c1461909199a5c0bd587df8d9ef652c650ac..21321a0f361203aacc78516ae25f21f35107da02 100644 (file)
@@ -60,7 +60,22 @@ You can set the following variables (also in your config.mak):
 
     GIT_PERF_MAKE_OPTS
        Options to use when automatically building a git tree for
-       performance testing.  E.g., -j6 would be useful.
+       performance testing. E.g., -j6 would be useful. Passed
+       directly to make as "make $GIT_PERF_MAKE_OPTS".
+
+    GIT_PERF_MAKE_COMMAND
+       An arbitrary command that'll be run in place of the make
+       command, if set the GIT_PERF_MAKE_OPTS variable is
+       ignored. Useful in cases where source tree changes might
+       require issuing a different make command to different
+       revisions.
+
+       This can be (ab)used to monkeypatch or otherwise change the
+       tree about to be built. Note that the build directory can be
+       re-used for subsequent runs so the make command might get
+       executed multiple times on the same tree, but don't count on
+       any of that, that's an implementation detail that might change
+       in the future.
 
     GIT_PERF_REPO
     GIT_PERF_LARGE_REPO
@@ -106,6 +121,7 @@ sources perf-lib.sh:
 
 After that you will want to use some of the following:
 
+       test_perf_fresh_repo    # sets up an empty repository
        test_perf_default_repo  # sets up a "normal" repository
        test_perf_large_repo    # sets up a "large" repository
 
@@ -115,8 +131,16 @@ After that you will want to use some of the following:
 
 At least one of the first two is required!
 
-You can use test_expect_success as usual.  For actual performance
-tests, use
+You can use test_expect_success as usual. In both test_expect_success
+and in test_perf, running "git" points to the version that is being
+perf-tested. The $MODERN_GIT variable points to the git wrapper for the
+currently checked-out version (i.e., the one that matches the t/perf
+scripts you are running).  This is useful if your setup uses commands
+that only work with newer versions of git than what you might want to
+test (but obviously your new commands must still create a state that can
+be used by the older version of git you are testing).
+
+For actual performance tests, use
 
        test_perf 'descriptive string' '
                command1 &&