1. 28 Jun, 2016 1 commit
  2. 03 May, 2016 1 commit
    • Junio C Hamano's avatar
      commit-tree: do not pay attention to commit.gpgsign · 66948561
      Junio C Hamano authored
      ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) introduced a
      "signed commit" by teaching the --[no]-gpg-sign option and the
      commit.gpgsign configuration variable to various commands that
      create commits.
      Teaching these to "git commit" and "git merge", both of which are
      end-user facing Porcelain commands, was perfectly fine.  Allowing
      the plumbing "git commit-tree" to suddenly change the behaviour to
      surprise the scripts by paying attention to commit.gpgsign was not.
      Among the in-tree scripts, filter-branch, quiltimport, rebase and
      stash are the commands that run "commit-tree".  If any of these
      wants to allow users to always sign every single commit, they should
      offer their own configuration (e.g. "filterBranch.gpgsign") with an
      option to disable signing (e.g. "git filter-branch --no-gpgsign").
      Ignoring commit.gpgsign option _obviously_ breaks the backward
      compatibility, but it is easy to follow the standard pattern in
      scripts to honor whatever configuration variable they choose to
      follow.  E.g.
      	case $(git config --bool commit.gpgsign) in
      	true) sign=-S ;;
      	*) sign= ;;
      	esac &&
      	git commit-tree $sign ...whatever other args...
      Do so to make sure that "git rebase" keeps paying attention to the
      configuration variable, which unfortunately is a documented mistake.
      Helped-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  3. 16 Oct, 2015 1 commit
    • Junio C Hamano's avatar
      usage: do not insist that standard input must come from a file · 33e8fc87
      Junio C Hamano authored
      The synopsys text and the usage string of subcommands that read list
      of things from the standard input are often shown like this:
      	git gostak [--distim] < <list-of-doshes>
      This is problematic in a number of ways:
       * The way to use these commands is more often to feed them the
         output from another command, not feed them from a file.
       * Manual pages outside Git, commands that operate on the data read
         from the standard input, e.g "sort", "grep", "sed", etc., are not
         described with such a "< redirection-from-file" in their synopsys
         text.  Our doing so introduces inconsistency.
       * We do not insist on where the output should go, by saying
      	git gostak [--distim] < <list-of-doshes> > <output>
       * As it is our convention to enclose placeholders inside <braket>,
         the redirection operator followed by a placeholder filename
         becomes very hard to read, both in the documentation and in the
         help text.
      Let's clean them all up, after making sure that the documentation
      clearly describes the modes that take information from the standard
      input and what kind of things are expected on the input.
      [jc: stole example for fmt-merge-msg from Jonathan]
      Helped-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  4. 21 Sep, 2015 1 commit
    • Matthieu Moy's avatar
      Documentation: explain optional arguments better · 2b594bf9
      Matthieu Moy authored
      Improve the documentation of commands taking optional arguments in two
      * Documents the behavior of '-O' (for grep) and '-S' (for commands
        creating commits) when used without the optional argument.
      * Document the syntax of these options.
      For the second point, the behavior is documented in gitcli(7), but it is
      easy for users to miss, and hard for the same user to understand why e.g.
      "git status -u no" does not work.
      Document this explicitly in the documentation of each short option having
      an optional argument: they are the most error prone since there is no '='
      sign between the option and its argument.
      Signed-off-by: default avatarMatthieu Moy <Matthieu.Moy@imag.fr>
      Reviewed-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  5. 14 Mar, 2015 1 commit
  6. 24 Feb, 2014 1 commit
  7. 25 Mar, 2013 1 commit
    • Brad King's avatar
      commit-tree: document -S option consistently · df45cb3e
      Brad King authored
      Commit ba3c69a9 (commit: teach --gpg-sign option, 2011-10-05) added the
      -S option but documented it in the command usage without indicating that
      the value is optional and forgot to mention it in the manpage.  Later
      commit 098bbdc3 (Add -S, --gpg-sign option to manpage of "git commit",
      2012-10-21) documented the option in the porcelain manpage.
      Use wording from the porcelain manpage to document the option in the
      plumbing manpage.  Also update the commit-tree usage summary to indicate
      that the -S value is optional to be consistent with the manpage and with
      the implementation.
      Signed-off-by: Brad King's avatarBrad King <brad.king@kitware.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 01 Feb, 2013 1 commit
  9. 10 Jan, 2013 1 commit
  10. 17 Jul, 2012 1 commit
  11. 19 Jun, 2012 2 commits
  12. 22 May, 2012 2 commits
    • Jeff King's avatar
      ident: report passwd errors with a more friendly message · 2f705875
      Jeff King authored
      When getpwuid fails, we give a cute but cryptic message.
      While it makes sense if you know that getpwuid or identity
      functions are being called, this code is triggered behind
      the scenes by quite a few git commands these days (e.g.,
      receive-pack on a remote server might use it for a reflog;
      the current message is hard to distinguish from an
      authentication error).  Let's switch to something that gives
      a little more context.
      While we're at it, we can factor out all of the
      cut-and-pastes of the "you don't exist" message into a
      wrapper function. Rather than provide xgetpwuid, let's make
      it even more specific to just getting the passwd entry for
      the current uid. That's the only way we use getpwuid anyway,
      and it lets us make an even more specific error message.
      The current message also fails to mention errno. While the
      usual cause for getpwuid failing is that the user does not
      exist, mentioning errno makes it easier to diagnose these
      problems.  Note that POSIX specifies that errno remain
      untouched if the passwd entry does not exist (but will be
      set on actual errors), whereas some systems will return
      ENOENT or similar for a missing entry. We handle both cases
      in our wrapper.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      drop length limitations on gecos-derived names and emails · 8587ead7
      Jeff King authored
      When we pull the user's name from the GECOS field of the
      passwd file (or generate an email address based on their
      username and hostname), we put the result into a
      static buffer. While it's extremely unlikely that anybody
      ever hit these limits (after all, in such a case their
      parents must have hated them), we still had to deal with the
      error cases in our code.
      Converting these static buffers to strbufs lets us simplify
      the code and drop some error messages from the documentation
      that have confused some users.
      The conversion is mostly mechanical: replace string copies
      with strbuf equivalents, and access the strbuf.buf directly.
      There are a few exceptions:
        - copy_gecos and copy_email are the big winners in code
          reduction (since they no longer have to manage the
          string length manually)
        - git_ident_config wants to replace old versions of
          the default name (e.g., if we read the config multiple
          times), so it must reset+add to the strbuf instead of
          just adding
      Note that there is still one length limitation: the
      gethostname interface requires us to provide a static
      buffer, so we arbitrarily choose 1024 bytes for the
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  13. 13 Nov, 2011 1 commit
  14. 03 Oct, 2011 1 commit
    • Jonathan Nieder's avatar
      ident: check /etc/mailname if email is unknown · 8a55caa8
      Jonathan Nieder authored
      Before falling back to gethostname(), check /etc/mailname if
      GIT_AUTHOR_EMAIL is not set in the environment or through config
      files.  Only fall back if /etc/mailname cannot be opened or read.
      The /etc/mailname convention comes from Debian policy section 11.6
      ("mail transport, delivery and user agents"), though maybe it could be
      useful sometimes on other machines, too.  The lack of this support was
      noticed by various people in different ways:
       - Ian observed that git was choosing the address
         'ian@anarres.relativity.greenend.org.uk' rather than
         'ian@davenant.greenend.org.uk' as it should have done.
       - Jonathan noticed that operations like "git commit" were needlessly
         slow when using a resolver that was slow to handle reverse DNS
      Alas, after this patch, if /etc/mailname is set up and the [user] name
      and email configuration aren't, the committer email will not provide a
      charming reminder of which machine commits were made on any more.  But
      I think it's worth it.
      Mechanics: the functionality of reading mailname goes in its own
      function, so people who care about other distros can easily add an
      implementation to a similar location without making copy_email() too
      long and losing clarity.  While at it, we split out the fallback
      default logic that does gethostname(), too (rearranging it a little
      and adding a check for errors from gethostname while at it).
      Based on a patch by Gerrit Pape <pape@smarden.org>.
      Requested-by: default avatarIan Jackson <ijackson@chiark.greenend.org.uk>
      Signed-off-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Improved-by: default avatarJunio C Hamano <gitster@pobox.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  15. 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 <martin.von.zweigbergk@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  16. 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 git@vger, and even if you
      wanted to cc the contact point, the out-of-date and
      incomplete fields mean you're likely sending to somebody
      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.
  17. 08 Oct, 2010 1 commit
  18. 20 Aug, 2010 1 commit
  19. 10 Jan, 2010 1 commit
    • 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
  20. 03 Dec, 2009 1 commit
  21. 03 Sep, 2008 1 commit
  22. 08 Aug, 2008 1 commit
  23. 05 Jul, 2008 1 commit
  24. 02 Jul, 2008 2 commits
    • Jonathan Nieder's avatar
      Documentation formatting and cleanup · 483bc4f0
      Jonathan Nieder authored
      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: default avatarJonathan Nieder <jrnieder@uchicago.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    • 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 <jrnieder@uchicago.edu>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  25. 06 Jun, 2008 1 commit
  26. 28 May, 2008 1 commit
  27. 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.
      +# Explicit so they can be nested.
       # Anchor: [[[id]]]. Bibliographic anchor.
       # 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 <dpmcgee@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  28. 25 Aug, 2007 1 commit
  29. 17 Aug, 2007 1 commit
  30. 15 Jul, 2007 1 commit
  31. 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 <gitster@pobox.com>
  32. 29 Apr, 2007 2 commits
  33. 18 Jan, 2007 1 commit
  34. 17 Jan, 2007 1 commit
  35. 30 Dec, 2006 1 commit
  36. 06 Jan, 2006 1 commit