1. 10 8月, 2010 1 次提交
  2. 18 2月, 2010 1 次提交
    • J
      docs: don't talk about $GIT_DIR/refs/ everywhere · cc1b8d8b
      Jeff King 提交于
      It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we
      may also consult the packed refs mechanism. These days we tend to treat
      the "refs hierarchy" as more of an abstract namespace that happens to be
      represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at
      worst it can confuse users who then look in $GIT_DIR/refs and find that it
      is missing some of the refs they expected to see.
      
      This patch drops most uses of "$GIT_DIR/refs/*", changing them into just
      "refs/*", under the assumption that users can handle the concept of an
      abstract refs namespace. There are a few things to note:
      
        - most cases just dropped the $GIT_DIR/ portion. But for cases where
          that left _just_ the word "refs", I changed it to "refs/" to help
          indicate that it was a hierarchy.  I didn't do the same for longer
          paths (e.g., "refs/heads" remained, instead of becoming
          "refs/heads/").
      
        - in some cases, no change was made, as the text was explicitly about
          unpacked refs (e.g., the discussion in git-pack-refs).
      
        - In some cases it made sense instead to note the existence of packed
          refs (e.g., in check-ref-format and rev-parse).
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cc1b8d8b
  3. 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
  4. 01 10月, 2008 1 次提交
  5. 06 7月, 2008 1 次提交
  6. 02 7月, 2008 2 次提交
    • J
      Documentation formatting and cleanup · 483bc4f0
      Jonathan Nieder 提交于
      Following what appears to be the predominant style, format
      names of commands and commandlines both as `teletype text`.
      
      While we're at it, add articles ("a" and "the") in some
      places, italicize the name of the command in the manual page
      synopsis line, and add a comma or two where it seems appropriate.
      Signed-off-by: NJonathan Nieder <jrnieder@uchicago.edu>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      483bc4f0
    • J
      Documentation: be consistent about "git-" versus "git " · b1889c36
      Jonathan Nieder 提交于
      Since the git-* commands are not installed in $(bindir), using
      "git-command <parameters>" in examples in the documentation is
      not a good idea. On the other hand, it is nice to be able to
      refer to each command using one hyphenated word. (There is no
      escaping it, anyway: man page names cannot have spaces in them.)
      
      This patch retains the dash in naming an operation, command,
      program, process, or action. Complete command lines that can
      be entered at a shell (i.e., without options omitted) are
      made to use the dashless form.
      
      The changes consist only of replacing some spaces with hyphens
      and vice versa. After a "s/ /-/g", the unpatched and patched
      versions are identical.
      Signed-off-by: NJonathan Nieder <jrnieder@uchicago.edu>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b1889c36
  7. 09 6月, 2008 1 次提交
    • S
      Docs: Use "-l::\n--long\n" format in OPTIONS sections · 3240240f
      Stephan Beyer 提交于
      The OPTIONS section of a documentation file contains a list
      of the options a git command accepts.
      
      Currently there are several variants to describe the case that
      different options (almost) do the same in the OPTIONS section.
      
      Some are:
      
       -f, --foo::
       -f|--foo::
       -f | --foo::
      
      But AsciiDoc has the special form:
      
       -f::
       --foo::
      
      This patch applies this form to the documentation of the whole git suite,
      and removes useless em-dash prevention, so \--foo becomes --foo.
      Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      3240240f
  8. 07 6月, 2008 1 次提交
  9. 29 5月, 2008 1 次提交
  10. 15 5月, 2008 1 次提交
  11. 30 4月, 2008 1 次提交
  12. 07 1月, 2008 1 次提交
    • D
      Documentation: rename gitlink macro to linkgit · 5162e697
      Dan McGee 提交于
      Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
      Asciidoc configuration:
      
      @@ -149,7 +153,10 @@
       # Inline macros.
       # Backslash prefix required for escape processing.
       # (?s) re flag for line spanning.
      -(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
      +
      +# Explicit so they can be nested.
      +(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
      +
       # Anchor: [[[id]]]. Bibliographic anchor.
       (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
       # Anchor: [[id,xreflabel]]
      
      This default regex now matches explicit values, and unfortunately in this
      case gitlink was being matched by just 'link', causing the wrong inline
      macro template to be applied. By renaming the macro, we can avoid being
      matched by the wrong regex.
      Signed-off-by: NDan McGee <dpmcgee@gmail.com>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5162e697
  13. 01 12月, 2007 1 次提交
    • J
      Add "--expire <time>" option to 'git prune' · f01913e4
      Johannes Schindelin 提交于
      Earlier, 'git prune' would prune all loose unreachable objects.
      This could be quite dangerous, as the objects could be used in
      an ongoing operation.
      
      This patch adds a mode to expire only loose, unreachable objects
      which are older than a certain time.  For example, by
      
      	git prune --expire 14.days
      
      you can prune only those objects which are loose, unreachable
      and older than 14 days (and thus probably outdated).
      
      The implementation uses st.st_mtime rather than st.st_ctime,
      because it can be tested better, using 'touch -d <time>' (and
      omitting the test when the platform does not support that
      command line switch).
      Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      f01913e4
  14. 10 6月, 2007 1 次提交
  15. 07 6月, 2007 1 次提交
    • J
      War on whitespace · a6080a0a
      Junio C Hamano 提交于
      This uses "git-apply --whitespace=strip" to fix whitespace errors that have
      crept in to our source files over time.  There are a few files that need
      to have trailing whitespaces (most notably, test vectors).  The results
      still passes the test, and build result in Documentation/ area is unchanged.
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a6080a0a
  16. 29 1月, 2007 1 次提交
  17. 22 1月, 2007 1 次提交
    • J
      Revert "prune: --grace=time" · 026aa938
      Junio C Hamano 提交于
      This reverts commit 9b088c4e.
      
      Protecting 'mature' objects does not make it any safer.  We should
      admit that git-prune is inherently unsafe when run in parallel with
      other operations without involving unwarranted locking overhead,
      and with the latest git, even rebase and reset would not immediately
      create crufts anyway.
      026aa938
  18. 21 1月, 2007 1 次提交
  19. 06 5月, 2006 1 次提交
  20. 09 12月, 2005 2 次提交
    • J
      git-prune: never lose objects reachable from our refs. · 2b86976b
      Junio C Hamano 提交于
      Explicit <head> arguments to git-prune replaces, instead of
      extends, the list of heads used for reachability analysis by
      fsck-objects.  By giving a subset of heads by mistake, objects
      reachable only from other heads can be removed, resulting in a
      corrupted repository.
      
      This commit stops replacing the list of heads, and makes the
      command line arguments to add to them instead for safety.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      2b86976b
    • J
      Documentation: git-prune · c82365dc
      Junio C Hamano 提交于
      Not replacing but always including our own refs may be more
      desirable (and unarguably much safer), but at the same time I
      have a suspicion that that might be forbidding a useful usage I
      haven't thought of, so...
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c82365dc
  21. 11 10月, 2005 1 次提交
  22. 21 9月, 2005 1 次提交
  23. 08 9月, 2005 1 次提交
    • J
      Big tool rename. · 215a7ad1
      Junio C Hamano 提交于
      As promised, this is the "big tool rename" patch.  The primary differences
      since 0.99.6 are:
      
        (1) git-*-script are no more.  The commands installed do not
            have any such suffix so users do not have to remember if
            something is implemented as a shell script or not.
      
        (2) Many command names with 'cache' in them are renamed with
            'index' if that is what they mean.
      
      There are backward compatibility symblic links so that you and
      Porcelains can keep using the old names, but the backward
      compatibility support  is expected to be removed in the near
      future.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      215a7ad1
  24. 30 8月, 2005 1 次提交
  25. 06 8月, 2005 1 次提交
  26. 11 5月, 2005 1 次提交