1. 26 Apr, 2012 1 commit
    • Jeff King's avatar
      docs: stop using asciidoc no-inline-literal · 6cf378f0
      Jeff King authored
      In asciidoc 7, backticks like `foo` produced a typographic
      effect, but did not otherwise affect the syntax. In asciidoc
      8, backticks introduce an "inline literal" inside which markup
      is not interpreted. To keep compatibility with existing
      documents, asciidoc 8 has a "no-inline-literal" attribute to
      keep the old behavior. We enabled this so that the
      documentation could be built on either version.
      
      It has been several years now, and asciidoc 7 is no longer
      in wide use. We can now decide whether or not we want
      inline literals on their own merits, which are:
      
        1. The source is much easier to read when the literal
           contains punctuation. You can use `master~1` instead
           of `master{tilde}1`.
      
        2. They are less error-prone. Because of point (1), we
           tend to make mistakes and forget the extra layer of
           quoting.
      
      This patch removes the no-inline-literal attribute from the
      Makefile and converts every use of backticks in the
      documentation to an inline literal (they must be cleaned up,
      or the example above would literally show "{tilde}" in the
      output).
      
      Problematic sites were found by grepping for '`.*[{\\]' and
      examined and fixed manually. The results were then verified
      by comparing the output of "html2text" on the set of
      generated html pages. Doing so revealed that in addition to
      making the source more readable, this patch fixes several
      formatting bugs:
      
        - HTML rendering used the ellipsis character instead of
          literal "..." in code examples (like "git log A...B")
      
        - some code examples used the right-arrow character
          instead of '->' because they failed to quote
      
        - api-config.txt did not quote tilde, and the resulting
          HTML contained a bogus snippet like:
      
            <tt><sub></tt> foo <tt></sub>bar</tt>
      
          which caused some parsers to choke and omit whole
          sections of the page.
      
        - git-commit.txt confused ``foo`` (backticks inside a
          literal) with ``foo'' (matched double-quotes)
      
        - mentions of `A U Thor <[email protected]>` used to
          erroneously auto-generate a mailto footnote for
          [email protected]
      
        - the description of --word-diff=plain incorrectly showed
          the output as "[-removed-] and {added}", not "{+added+}".
      
        - using "prime" notation like:
      
            commit `C` and its replacement `C'`
      
          confused asciidoc into thinking that everything between
          the first backtick and the final apostrophe were meant
          to be inside matched quotes
      
        - asciidoc got confused by the escaping of some of our
          asterisks. In particular,
      
            `credential.\*` and `credential.<url>.\*`
      
          properly escaped the asterisk in the first case, but
          literally passed through the backslash in the second
          case.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      6cf378f0
  2. 23 Nov, 2011 1 commit
  3. 22 Nov, 2011 1 commit
    • Jonathan Nieder's avatar
      revert: rename --reset option to --quit · f80a8726
      Jonathan Nieder authored
      The option to "git cherry-pick" and "git revert" to discard the
      sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
      --reset to remove sequencer state, 2011-08-04) has a confusing name.
      Change it now, while we still have the time.
      
      The new name for "cherry-pick, please get out of my way, since I've
      long forgotten about the sequence of commits I was cherry-picking when
      you wrote that old .git/sequencer directory" is --quit.  Mnemonic:
      this is analagous to quiting a program the user is no longer using ---
      we just want to get out of the multiple-command cherry-pick procedure
      and not to reset HEAD or rewind any other old state.
      
      The "--reset" option is kept as a synonym to minimize the impact.  We
      might consider dropping it for simplicity in a separate patch, though.
      
      Adjust documentation and tests to use the newly preferred name (--quit)
      instead of --reset.  While at it, let's clarify the short descriptions
      of these operations in "-h" output.
      
      Before:
      
      	--reset		forget the current operation
      	--continue	continue the current operation
      
      After:
      
      	--quit		end revert or cherry-pick sequence
      	--continue	resume revert or cherry-pick sequence
      Noticed-by: Phil Hord's avatarPhil Hord <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      f80a8726
  4. 08 Aug, 2011 1 commit
    • Ramkumar Ramachandra's avatar
      revert: Introduce --continue to continue the operation · 5a5d80f4
      Ramkumar Ramachandra authored
      Introduce a new "git cherry-pick --continue" command which uses the
      information in ".git/sequencer" to continue a cherry-pick that stopped
      because of a conflict or other error.  It works by dropping the first
      instruction from .git/sequencer/todo and performing the remaining
      cherry-picks listed there, with options (think "-s" and "-X") from the
      initial command listed in ".git/sequencer/opts".
      
      So now you can do:
      
        $ git cherry-pick -Xpatience foo..bar
        ... description conflict in commit moo ...
        $ git cherry-pick --continue
        error: 'cherry-pick' is not possible because you have unmerged files.
        fatal: failed to resume cherry-pick
        $ echo resolved >conflictingfile
        $ git add conflictingfile && git commit
        $ git cherry-pick --continue; # resumes with the commit after "moo"
      
      During the "git commit" stage, CHERRY_PICK_HEAD will aid by providing
      the commit message from the conflicting "moo" commit.  Note that the
      cherry-pick mechanism has no control at this stage, so the user is
      free to violate anything that was specified during the first
      cherry-pick invocation.  For example, if "-x" was specified during the
      first cherry-pick invocation, the user is free to edit out the message
      during commit time.  Note that the "--signoff" option specified at
      cherry-pick invocation time is not reflected in the commit message
      provided by CHERRY_PICK_HEAD; the user must take care to add
      "--signoff" during the "git commit" invocation.
      Helped-by: Christian Couder's avatarChristian Couder <[email protected]>
      Signed-off-by: default avatarRamkumar Ramachandra <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5a5d80f4
  5. 04 Aug, 2011 2 commits
    • Jeff King's avatar
      docs: put listed example commands in backticks · 5d2fc913
      Jeff King authored
      Many examples of git command invocation are given in asciidoc listing
      blocks, which makes them monospaced and avoids further interpretation of
      special characters.  Some manpages make a list of examples, like:
      
        git foo::
          Run git foo.
      
        git foo -q::
          Use the "-q" option.
      
      to quickly show many variants. However, they can sometimes be hard to
      read, because they are shown in a proportional-width font (so, for
      example, seeing the difference between "-- foo" and "--foo" can be
      difficult).
      
      This patch puts all such examples into backticks, which gives the
      equivalent formatting to a listing block (i.e., monospaced and without
      character interpretation).
      
      As a bonus, this also fixes an example in the git-push manpage, in which
      "git push origin :::" was accidentally considered a newly-indented list,
      and not a list item with "git push origin :" in it.
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5d2fc913
    • Ramkumar Ramachandra's avatar
      revert: Introduce --reset to remove sequencer state · 26ae337b
      Ramkumar Ramachandra authored
      To explicitly remove the sequencer state for a fresh cherry-pick or
      revert invocation, introduce a new subcommand called "--reset" to
      remove the sequencer state.
      
      Take the opportunity to publicly expose the sequencer paths, and a
      generic function called "remove_sequencer_state" that various git
      programs can use to remove the sequencer state in a uniform manner;
      "git reset" uses it later in this series.  Introducing this public API
      is also in line with our long-term goal of eventually factoring out
      functions from revert.c into a generic commit sequencer.
      Signed-off-by: default avatarRamkumar Ramachandra <[email protected]>
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      26ae337b
  6. 06 Jul, 2011 1 commit
    • Martin von Zweigbergk's avatar
      Documentation: use [verse] for SYNOPSIS sections · 7791a1d9
      Martin von Zweigbergk authored
      The SYNOPSIS sections of most commands that span several lines already
      use [verse] to retain line breaks. Most commands that don't span
      several lines seem not to use [verse]. In the HTML output, [verse]
      does not only preserve line breaks, but also makes the section
      indented, which causes a slight inconsistency between commands that
      use [verse] and those that don't. Use [verse] in all SYNOPSIS sections
      for consistency.
      
      Also remove the blank lines from git-fetch.txt and git-rebase.txt to
      align with the other man pages. In the case of git-rebase.txt, which
      already uses [verse], the blank line makes the [verse] not apply to
      the last line, so removing the blank line also makes the formatting
      within the document more consistent.
      
      While at it, add single quotes to 'git cvsimport' for consistency with
      other commands.
      Signed-off-by: default avatarMartin von Zweigbergk <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      7791a1d9
  7. 29 Jun, 2011 1 commit
    • Jonathan Nieder's avatar
      Documentation: quote double-dash for AsciiDoc · 565e135a
      Jonathan Nieder authored
      AsciiDoc versions since 5.0.6 treat a double-dash surrounded by spaces
      (outside of verbatim environments) as a request to insert an em dash.
      Such versions also treat the three-character sequence "\--", when not
      followed by another dash, as a request to insert two literal minus
      signs.  Thus from time to time there have been patches to add
      backslashes to AsciiDoc markup to escape double-dashes that are meant
      to be represent '--' characters used literally on the command line;
      see v1.4.0-rc1~174, Fix up docs where "--" isn't displayed correctly,
      2006-05-05, for example.
      
      AsciiDoc 6.0.3 (2005-04-20) made life harder by also treating
      double-dashes without surrounding whitespace as markup for an em dash,
      though only when formatting for backends other than the manpages
      (e.g., HTML).  Many pages needed to be changed to use a backslash
      before the "--" in names of command-line flags like "--add" (see
      v0.99.6~37, Update tutorial, 2005-08-30).
      
      AsciiDoc 8.3.0 (2008-11-29) refined the em-dash rule to avoid that
      requirement.  Double-dashes without surrounding spaces are not
      rendered as em dashes any more unless bordered on both sides by
      alphanumeric characters.  The unescaped markup for option names (e.g.,
      "--add") works fine, and many instances of this style have leaked into
      Documentation/; git's HTML documentation contains many spurious em
      dashes when formatted by an older toolchain.  (This patch will not
      change that.)
      
      The upshot: "--" as an isolated word and in phrases like "git
      web--browse" must be escaped if it is not to be rendered as an em dash
      by current asciidoc.  Use "\--" to avoid such misformatting in
      sentences in which "--" represents a literal double-minus command line
      argument that separates options and revs from pathspecs, and use
      "{litdd}" in cases where the double-dash is embedded in the command
      name.  The latter is just for consistency with v1.7.3-rc0~13^2 (Work
      around em-dash handling in newer AsciiDoc, 2010-08-23).
      
      List of lines to fix found by grepping manpages for "(em".
      Signed-off-by: default avatarJonathan Nieder <[email protected]>
      Improved-by: default avatarJunio C Hamano <[email protected]>
      Improved-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      565e135a
  8. 11 Mar, 2011 1 commit
    • Jeff King's avatar
      doc: drop author/documentation sections from most pages · 48bb914e
      Jeff King authored
      The point of these sections is generally to:
      
        1. Give credit where it is due.
      
        2. Give the reader an idea of where to ask questions or
           file bug reports.
      
      But they don't do a good job of either case. For (1), they
      are out of date and incomplete. A much more accurate answer
      can be gotten through shortlog or blame.  For (2), the
      correct contact point is generally [email protected], and even if you
      wanted to cc the contact point, the out-of-date and
      incomplete fields mean you're likely sending to somebody
      useless.
      
      So let's drop the fields entirely from all manpages except
      git(1) itself. We already point people to the mailing list
      for bug reports there, and we can update the Authors section
      to give credit to the major contributors and point to
      shortlog and blame for more information.
      
      Each page has a "This is part of git" footer, so people can
      follow that to the main git manpage.
      48bb914e
  9. 28 Dec, 2010 1 commit
  10. 02 Dec, 2010 1 commit
  11. 14 Oct, 2010 1 commit
  12. 05 Jul, 2010 1 commit
  13. 02 Jun, 2010 1 commit
  14. 10 Jan, 2010 2 commits
    • Thomas Rast's avatar
      Documentation: spell 'git cmd' without dash throughout · 0b444cdb
      Thomas Rast authored
      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
    • Thomas Rast's avatar
      Documentation: format full commands in typewriter font · ca768288
      Thomas Rast authored
      Use `code snippet` style instead of 'emphasis' for `git cmd ...`
      according to the following rules:
      
      * The SYNOPSIS sections are left untouched.
      
      * If the intent is that the user type the command exactly as given, it
        is `code`.
        If the user is only loosely referred to a command and/or option, it
        remains 'emphasised'.
      Signed-off-by: default avatarThomas Rast <[email protected]>
      ca768288
  15. 22 Dec, 2008 1 commit
  16. 20 Aug, 2008 1 commit
  17. 02 Aug, 2008 1 commit
  18. 21 Jul, 2008 1 commit
  19. 16 Jul, 2008 1 commit
  20. 05 Jul, 2008 1 commit
  21. 02 Jul, 2008 1 commit
    • Jonathan Nieder's avatar
      Documentation: be consistent about "git-" versus "git " · b1889c36
      Jonathan Nieder authored
      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: default avatarJonathan Nieder <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      b1889c36
  22. 08 Jun, 2008 1 commit
    • Stephan Beyer's avatar
      Docs: Use "-l::\n--long\n" format in OPTIONS sections · 3240240f
      Stephan Beyer authored
      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: default avatarStephan Beyer <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      3240240f
  23. 06 Jun, 2008 1 commit
  24. 26 Apr, 2008 1 commit
  25. 19 Jan, 2008 1 commit
  26. 07 Jan, 2008 1 commit
    • Dan McGee's avatar
      Documentation: rename gitlink macro to linkgit · 5162e697
      Dan McGee authored
      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: Dan McGee's avatarDan McGee <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5162e697
  27. 27 Oct, 2007 1 commit
    • Junio C Hamano's avatar
      revert/cherry-pick: work on merge commits as well · 7791ecbc
      Junio C Hamano authored
      Usually you cannot revert a merge because you do not know which
      side of the merge should be considered the mainline (iow, what
      change to reverse).
      
      With this patch, cherry-pick and revert learn -m (--mainline)
      option that lets you specify the parent number (starting from 1)
      of the mainline, so that you can:
      
      	git revert -m 1 $merge
      
      to reverse the changes introduced by the $merge commit relative
      to its first parent, and:
      
      	git cherry-pick -m 2 $merge
      
      to replay the changes introduced by the $merge commit relative
      to its second parent.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      7791ecbc
  28. 07 Jun, 2007 1 commit
    • Junio C Hamano's avatar
      War on whitespace · a6080a0a
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
      a6080a0a
  29. 18 Jan, 2007 1 commit
  30. 09 Mar, 2006 1 commit
  31. 08 Dec, 2005 1 commit
  32. 05 Dec, 2005 1 commit
  33. 03 Oct, 2005 1 commit
    • Jonas Fonseca's avatar
      [PATCH] Random documentation fixes · df8baa42
      Jonas Fonseca authored
      The fixes focuses on improving the HTML output. Most noteworthy:
      
       - Fix the Makefile to also make various *.html files depend on
         included files.
      
       - Consistently use 'NOTE: ...' instead of '[ ... ]' for additional
         info.
      
       - Fix ending '::' for description lists in OPTION section etc.
      
       - Fix paragraphs in description lists ending up as preformated text.
      
       - Always use listingblocks (preformatted text wrapped in lines with -----)
         for examples that span empty lines, so they are put in only one HTML
         block.
      
       - Use '1.' instead of '(1)' for numbered lists.
      
       - Fix linking to other GIT docs.
      
       - git-rev-list.txt: put option descriptions in an OPTION section.
      Signed-off-by: default avatarJonas Fonseca <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      df8baa42
  34. 20 Sep, 2005 1 commit
  35. 08 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Big tool rename. · 215a7ad1
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
      215a7ad1
  36. 29 Aug, 2005 1 commit
  37. 27 Aug, 2005 1 commit
  38. 23 Aug, 2005 1 commit