1. 21 3月, 2013 1 次提交
    • J
      do not use GIT_TRACE_PACKET=3 in tests · 2ad23273
      Jeff King 提交于
      Some test scripts use the GIT_TRACE mechanism to dump
      debugging information to descriptor 3 (and point it to a
      file using the shell). On Windows, however, bash is unable
      to set up descriptor 3. We do not write our trace to the
      file, and worse, we may interfere with other operations
      happening on descriptor 3, causing tests to fail or even
      behave inconsistently.
      
      Prior to commit 97a83fa8 (upload-pack: remove packet debugging
      harness), these tests used GIT_DEBUG_SEND_PACK, which only
      supported output to a descriptor. The tests in t5503 were
      always broken on Windows, and were marked to be skipped via
      the NOT_MINGW prerequisite. In t5700, the tests used to pass
      prior to 97a83fa8, but only because they were not careful
      enough; because we only grepped the trace file, an empty
      file looked successful to us. But post-97a83fa8, the writing
      to descriptor 3 causes "git fetch" to hang (presumably
      because we are throwing random bytes into the middle of the
      protocol).
      
      Now that we are using the GIT_TRACE mechanism, we can
      improve both scripts by asking git to write directly to a
      file rather than a descriptor. That fixes the hang in t5700,
      and should allow t5503 to successfully run on Windows.
      
      In both cases we now also use "test -s" to double-check that
      our trace file actually contains output, which should reduce
      the possibility of an erroneously passing test.
      Signed-off-by: NJeff King <peff@peff.net>
      Tested-by: NJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      2ad23273
  2. 21 2月, 2013 1 次提交
    • J
      upload-pack: remove packet debugging harness · 97a83fa8
      Jeff King 提交于
      If you set the GIT_DEBUG_SEND_PACK environment variable,
      upload-pack will dump lines it receives in the receive_needs
      phase to a descriptor. This debugging harness is a strict
      subset of what GIT_TRACE_PACKET can do. Let's just drop it
      in favor of that.
      
      A few tests used GIT_DEBUG_SEND_PACK to confirm which
      objects get sent; we have to adapt them to the new output
      format.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      97a83fa8
  3. 10 11月, 2010 1 次提交
  4. 09 10月, 2010 1 次提交
  5. 02 10月, 2010 1 次提交
    • P
      Skip t1300.70 and 71 on msysGit. · 3ba9ba8f
      Pat Thoyts 提交于
      These two tests fail on msysGit because /dev/null is an alias for nul on
      Windows and when reading the value back from git config the alias does
      not match the real filename. Also the HOME environment variable has a
      unix-style path but git returns a native equivalent path for '~'.  As
      these are platform-dependent equivalent results it seems simplest to
      skip the test entirely.
      
      Moves the NOT_MINGW prereq from t5503 into the test library.
      Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
      3ba9ba8f
  6. 19 8月, 2010 1 次提交
  7. 26 6月, 2010 1 次提交
  8. 05 4月, 2009 1 次提交
  9. 23 3月, 2009 1 次提交
    • J
      t5503: GIT_DEBUG_SEND_PACK is not supported on MinGW · 8b02c64a
      Johannes Sixt 提交于
      The test opens fd 3 and instructs git-upload-pack (via GIT_DEBUG_SEND_PACK)
      to log information to that channel.
      
      The way in which new processes are spawned by git on MinGW does not inherit
      all file descriptors to the child processes, but only 0, 1, and 2.
      The tests in t5503 require that file descriptor 3 is inherited from
      git-fetch to git-upload-pack.
      
      A complete implementation is non-trivial and not warranted just to satisfy
      this test.  Note that the incompleteness applies only to the executables
      that use compat/mingw.c; bash and perl (the other important executables
      used by git) are complete, of course.
      Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
      8b02c64a
  10. 24 5月, 2008 1 次提交
  11. 05 3月, 2008 1 次提交
    • S
      Teach git-fetch to exploit server side automatic tag following · 41fa7d2e
      Shawn O. Pearce 提交于
      If the remote peer upload-pack process supports the include-tag
      protocol extension then we can avoid running a second fetch cycle
      on the client side by letting the server send us the annotated tags
      along with the objects it is packing for us.  In the following graph
      we can now fetch both "tag1" and "tag2" on the same connection that
      we fetched "master" from the remote when we only have L available
      on the local side:
      
               T - tag1          S - tag2
              /                 /
         L - o ------ o ------ B
          \                     \
           \                     \
            origin/master         master
      
      The objects for "tag1" are implicitly downloaded without our direct
      knowledge.  The existing "quickfetch" optimization within git-fetch
      discovers that tag1 is complete after the first connection and does
      not open a second connection.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      41fa7d2e
  12. 03 3月, 2008 1 次提交
    • S
      Teach git-fetch to grab a tag at the same time as a commit · cf7f929a
      Shawn O. Pearce 提交于
      If the situation is the following on the remote and L is the common
      base between both sides:
      
                T - tag1    S - tag2
               /           /
          L - A - O - O - B
           \               \
            origin/master   master
      
      and we have decided to fetch "master" to acquire the range L..B we
      can also nab tag S at the same time during the first connection,
      as we can clearly see from the refs advertised by upload-pack that
      S^{} = B and master = B.
      
      Unfortunately we still cannot nab T at the same time as we are not
      able to see that T^{} will also be in the range implied by L..B.
      Such computations must be performed on the remote side (not yet
      supported) or on the client side as post-processing (the current
      behavior).
      
      This optimization is an extension of the previous one in that it
      helps on projects which tend to publish both a new commit and a
      new tag, then lay idle for a while before publishing anything else.
      Most followers are able to download both the new commit and the new
      tag in one connection, rather than two.  git.git tends to follow
      such patterns with its roughly once-daily updates from Junio.
      
      A protocol extension and additional server side logic would be
      necessary to also ensure T is grabbed on the first connection.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cf7f929a