1. 12 2月, 2011 1 次提交
  2. 31 1月, 2011 1 次提交
  3. 25 1月, 2011 1 次提交
  4. 06 1月, 2011 1 次提交
  5. 23 12月, 2010 1 次提交
  6. 17 12月, 2010 1 次提交
  7. 10 12月, 2010 1 次提交
  8. 22 10月, 2010 1 次提交
  9. 14 10月, 2010 1 次提交
  10. 09 10月, 2010 1 次提交
  11. 30 9月, 2010 1 次提交
  12. 19 9月, 2010 1 次提交
  13. 07 9月, 2010 1 次提交
  14. 04 9月, 2010 1 次提交
  15. 01 9月, 2010 1 次提交
  16. 20 8月, 2010 1 次提交
  17. 03 8月, 2010 1 次提交
  18. 28 7月, 2010 3 次提交
  19. 22 7月, 2010 1 次提交
  20. 06 7月, 2010 1 次提交
  21. 01 7月, 2010 1 次提交
  22. 24 4月, 2010 1 次提交
  23. 23 4月, 2010 1 次提交
  24. 12 4月, 2010 1 次提交
  25. 05 4月, 2010 2 次提交
    • J
      Rename ONE_FILESYSTEM to DISCOVERY_ACROSS_FILESYSTEM · cf87463e
      Junio C Hamano 提交于
      If a missing ONE_FILESYSTEM defaults to true, the only users who set this
      variable set it to false to tell git not to limit the discovery to one
      filesystem; there are too many negations in one sentence to make a simple
      panda brain dizzy.
      
      Use the variable GIT_DISCOVERY_ACROSS_FILESYSTEM that changes the
      behaviour from the default "limit to one filesystem" to "cross the
      boundary as I ask you to"; makes the semantics much more straight
      forward.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cf87463e
    • J
      GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries · e6405517
      Junio C Hamano 提交于
      Regarding the new environment variable, Linus Torvalds
      <torvalds@linux-foundation.org> writes on Tue, 30 Mar 2010 in
      <alpine.LFD.2.00.1003301537150.3707@i5.linux-foundation.org>:
      
          I suspect that it is _very_ unusual to have a source repo that crosses
          multiple filesystems, and the original reason for this patch-series
          seems to me to be likely to be more common than that multi-fs case. So
          having the logic go the other way would seem to match the common case,
          no?
      
      The "crossing filesystem boundary" condition is checked by comparing
      st_dev field in the result from stat(2).  This is slightly worrysome if
      non-POSIX ports return different values in the field even for directories
      in the same work tree extracted to the same "filesystem".  Erik Faye-Lund
      confirms that in the msysgit port st_dev is 0, so this should be safe, as
      "even Windows is safe" ;-)
      
      This will affect those who use /.git to cram /etc and /home/me in the same
      repostiory, /home is mounted from non-root filesystem, and a git operation
      is done from inside /home/me/src.  But that is such a corner case we don't
      want to give preference over helping people who will benefit from having
      this default so that they do not have to suffer from slow automounters.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e6405517
  26. 01 4月, 2010 1 次提交
  27. 29 3月, 2010 2 次提交
  28. 22 3月, 2010 1 次提交
  29. 08 3月, 2010 1 次提交
  30. 01 3月, 2010 1 次提交
  31. 15 2月, 2010 1 次提交
  32. 13 2月, 2010 1 次提交
  33. 11 2月, 2010 1 次提交
  34. 21 1月, 2010 2 次提交
  35. 10 1月, 2010 1 次提交
    • T
      Documentation: spell 'git cmd' without dash throughout · 0b444cdb
      Thomas Rast 提交于
      The documentation was quite inconsistent when spelling 'git cmd' if it
      only refers to the program, not to some specific invocation syntax:
      both 'git-cmd' and 'git cmd' spellings exist.
      
      The current trend goes towards dashless forms, and there is precedent
      in 647ac702 (git-svn.txt: stop using dash-form of commands.,
      2009-07-07) to actively eliminate the dashed variants.
      
      Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
      git-cvsserver, git-upload-pack, git-receive-pack, and
      git-upload-archive are concerned, because those really live in the
      $PATH.
      0b444cdb