1. 26 3月, 2015 1 次提交
  2. 27 11月, 2013 1 次提交
  3. 30 7月, 2013 1 次提交
    • L
      Avoid using `echo -n` anywhere · 19c3c5fd
      Lukas Fleischer 提交于
      `echo -n` is non-portable. The POSIX specification says:
      
          Conforming applications that wish to do prompting without <newline>
          characters or that could possibly be expecting to echo a -n, should
          use the printf utility derived from the Ninth Edition system.
      
      Since all of the affected shell scripts use a POSIX shell shebang,
      replace `echo -n` invocations with printf.
      Signed-off-by: NLukas Fleischer <git@cryptocrack.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      19c3c5fd
  4. 30 6月, 2013 1 次提交
  5. 27 9月, 2012 1 次提交
  6. 18 9月, 2012 1 次提交
    • J
      MALLOC_CHECK: various clean-ups · 1b3185fc
      Junio C Hamano 提交于
      The most important in this change is to avoid affecting anything
      when test-lib is used from perf-lib.  It also limits the effect of
      the MALLOC_CHECK only to what is run inside the actual test, and
      uses a fixed MALLOC_PERTURB_ in order to avoid hurting repeatability
      of the tests.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1b3185fc
  7. 05 8月, 2012 1 次提交
    • M
      tests: Introduce test_seq · d17cf5f3
      Michał Kiedrowicz 提交于
      Jeff King wrote:
      
      	The seq command is GNU-ism, and is missing at least in older BSD
      	releases and their derivatives, not to mention antique
      	commercial Unixes.
      
      	We already purged it in b3431bc6 (Don't use seq in tests, not
      	everyone has it, 2007-05-02), but a few new instances have crept
      	in. They went unnoticed because they are in scripts that are not
      	run by default.
      
      Replace them with test_seq that is implemented with a Perl snippet
      (proposed by Jeff).  This is better than inlining this snippet
      everywhere it's needed because it's easier to read and it's easier
      to change the implementation (e.g. to C) if we ever decide to remove
      Perl from the test suite.
      
      Note that test_seq is not a complete replacement for seq(1).  It
      just has what we need now, in addition that it makes it possible for
      us to do something like "test_seq a m" if we wanted to in the
      future.
      
      There are also many places that do `for i in 1 2 3 ...` but I'm not sure
      if it's worth converting them to test_seq.  That would introduce running
      more processes of Perl.
      Signed-off-by: NMichał Kiedrowicz <michal.kiedrowicz@gmail.com>
      Acked-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      d17cf5f3
  8. 09 3月, 2012 2 次提交
  9. 18 2月, 2012 1 次提交
    • T
      Introduce a performance testing framework · 342e9ef2
      Thomas Rast 提交于
      This introduces a performance testing framework under t/perf/.  It
      tries to be as close to the test-lib.sh infrastructure as possible,
      and thus should be easy to get used to for git developers.
      
      The following points were considered for the implementation:
      
      1. You usually want to compare arbitrary revisions/build trees against
         each other.  They may not have the performance test under
         consideration, or even the perf-lib.sh infrastructure.
      
         To cope with this, the 'run' script lets you specify arbitrary
         build dirs and revisions.  It even automatically builds the revisions
         if it doesn't have them at hand yet.
      
      2. Usually you would not want to run all tests.  It would take too
         long anyway.  The 'run' script lets you specify which tests to run;
         or you can also do it manually.  There is a Makefile for
         discoverability and 'make clean', but it is not meant for
         real-world use.
      
      3. Creating test repos from scratch in every test is extremely
         time-consuming, and shipping or downloading such large/weird repos
         is out of the question.
      
         We leave this decision to the user.  Two different sizes of test
         repos can be configured, and the scripts just copy one or more of
         those (using hardlinks for the object store).  By default it tries
         to use the build tree's git.git repository.
      
         This is fairly fast and versatile.  Using a copy instead of a clone
         preserves many properties that the user may want to test for, such
         as lots of loose objects, unpacked refs, etc.
      Signed-off-by: NThomas Rast <trast@student.ethz.ch>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      342e9ef2