This project is mirrored from Updated .
  1. 29 Oct, 2013 1 commit
    • Jeff King's avatar
      t: use perl instead of "$PERL_PATH" where applicable · 94221d22
      Jeff King authored
      As of the last commit, we can use "perl" instead of
      "$PERL_PATH" when running tests, as the former is now a
      function which uses the latter. As the shorter "perl" is
      easier on the eyes, let's switch to using it everywhere.
      This is not quite a mechanical s/$PERL_PATH/perl/
      replacement, though. There are some places where we invoke
      perl from a script we generate on the fly, and those scripts
      do not have access to our internal shell functions. The
      result can be double-checked by running:
        ln -s /bin/false bin-wrappers/perl
        make test
      which continues to pass even after this patch.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  2. 25 Jun, 2012 1 commit
  3. 12 Jun, 2012 1 commit
    • Vincent van Ravesteijn's avatar
      t: Replace 'perl' by $PERL_PATH · a3428205
      Vincent van Ravesteijn authored
      GIT-BUILD-OPTIONS defines PERL_PATH to be used in the test suite. Only a
      few tests already actually use this variable when perl is needed. The
      other test just call 'perl' and it might happen that the wrong perl
      interpreter is used.
      This becomes problematic on Windows, when the perl interpreter that is
      compiled and installed on the Windows system is used, because this perl
      interpreter might introduce some unexpected LF->CRLF conversions.
      This patch makes sure that $PERL_PATH is used everywhere in the test suite
      and that the correct perl interpreter is used.
      Signed-off-by: default avatarVincent van Ravesteijn <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  4. 06 Sep, 2010 1 commit
  5. 21 May, 2009 1 commit
    • Eygene Ryabinkin's avatar
      git-svn testsuite: use standard configuration for Subversion tools · da083d68
      Eygene Ryabinkin authored
      I have tweaked configuration in my ~/.subversion directory, namely I am
      running auto-properties and automatically adding '$Id$' expansion to
      every file.  This choke the last test named 'proplist' from, because one more property, svn:keywords is
      automatically added.
      I had just wrapped svn invocation with the svn_cmd that specifies empty
      directory via --config-dir argument.  Since the latter is the global
      option, it should be recognized by all svn subcommands, so no
      regressions will be introduced.
      Now svn_cmd is used everywhere, not just in the failed test module: this
      should guard us from the future clashes with user-defined configuration
      Signed-off-by: default avatarEygene Ryabinkin <[email protected]>
      Acked-by: default avatarEric Wong <[email protected]>
  6. 14 Mar, 2009 1 commit
  7. 08 Sep, 2008 1 commit
  8. 13 Jul, 2008 1 commit
  9. 26 Jun, 2008 1 commit
  10. 05 May, 2008 1 commit
    • Bryan Donlan's avatar
      Fix tests breaking when checkout path contains shell metacharacters · f69e836f
      Bryan Donlan authored
      This fixes the remainder of the issues where the test script itself is at
      fault for failing when the git checkout path contains whitespace or other
      shell metacharacters.
      The majority of git svn tests used the idiom
        test_expect_success "title" "test script using $svnrepo"
      These were changed to have the test script in single-quotes:
        test_expect_success "title" 'test script using "$svnrepo"'
      which unfortunately makes the patch appear larger than it really is.
      One consequence of this change is that in the verbose test output the
      value of $svnrepo (and in some cases other variables, too) is no
      longer expanded, i.e. previously we saw
        * expecting success:
      	test script using /path/to/git/t/trash/svnrepo
      but now it is:
        * expecting success:
      	test script using "$svnrepo"
      Signed-off-by: default avatarBryan Donlan <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  11. 02 Feb, 2008 1 commit
    • Junio C Hamano's avatar
      Sane use of test_expect_failure · 41ac414e
      Junio C Hamano authored
      Originally, test_expect_failure was designed to be the opposite
      of test_expect_success, but this was a bad decision.  Most tests
      run a series of commands that leads to the single command that
      needs to be tested, like this:
          test_expect_{success,failure} 'test title' '
      	setup1 &&
              setup2 &&
              setup3 &&
              what is to be tested
      And expecting a failure exit from the whole sequence misses the
      point of writing tests.  Your setup$N that are supposed to
      succeed may have failed without even reaching what you are
      trying to test.  The only valid use of test_expect_failure is to
      check a trivial single command that is expected to fail, which
      is a minority in tests of Porcelain-ish commands.
      This large-ish patch rewrites all uses of test_expect_failure to
      use test_expect_success and rewrites the condition of what is
      tested, like this:
          test_expect_success 'test title' '
      	setup1 &&
              setup2 &&
              setup3 &&
              ! this command should fail
      test_expect_failure is redefined to serve as a reminder that
      that test *should* succeed but due to a known breakage in git it
      currently does not pass.  So if git-foo command should create a
      file 'bar' but you discovered a bug that it doesn't, you can
      write a test like this:
          test_expect_failure 'git-foo should create bar' '
              rm -f bar &&
              git foo &&
              test -f bar
      This construct acts similar to test_expect_success, but instead
      of reporting "ok/FAIL" like test_expect_success does, the
      outcome is reported as "FIXED/still broken".
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  12. 22 Nov, 2007 1 commit
  13. 12 Nov, 2007 1 commit
  14. 05 Nov, 2007 1 commit
    • Eric Wong's avatar
      git-svn: fix dcommit clobbering when committing a series of diffs · c74d9acf
      Eric Wong authored
      Our revision number sent to SVN is set to the last revision we
      committed if we've made any previous commits in a dcommit
      Although our SVN Editor code uses the delta of two (old) trees
      to generate information to send upstream, it'll still send
      complete resultant files upstream; even if the tree they're
      based against is out-of-date.
      The combination of sending a file that does not include the
      latest changes, but set with a revision number of a commit we
      just made will cause SVN to accept the resultant file even if it
      was generated against an old tree.
      More trouble was caused when fixing this because we were
      rebasing uncessarily at times.  We used git-diff-tree to check
      the imported SVN revision against our HEAD, not the last tree we
      committed to SVN.  The unnecessary rebasing caused merge commits
      upstream to SVN to fail.
      Signed-off-by: default avatarEric Wong <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>