1. 27 Jan, 2014 1 commit
  2. 22 Jan, 2014 1 commit
  3. 19 Nov, 2013 2 commits
  4. 18 Nov, 2013 1 commit
  5. 22 Jan, 2013 1 commit
  6. 14 Sep, 2012 1 commit
  7. 08 Sep, 2011 1 commit
    • Michał Górny's avatar
      for-each-ref: add split message parts to %(contents:*). · e2b23972
      Michał Górny authored
      The %(body) placeholder returns the whole body of a tag or
      commit, including the signature. However, callers may want
      to get just the body without signature, or just the
      Rather than change the meaning of %(body), which might break
      some scripts, this patch introduces a new set of
      placeholders which break down the %(contents) placeholder
      into its constituent parts.
      [jk: initial patch by mg, rebased on top of my refactoring
      and with tests by me]
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  8. 09 Mar, 2011 2 commits
  9. 08 Oct, 2010 1 commit
  10. 20 Aug, 2010 1 commit
  11. 19 May, 2010 1 commit
  12. 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
  13. 13 Apr, 2009 1 commit
  14. 08 Apr, 2009 1 commit
  15. 06 Sep, 2008 1 commit
    • Bert Wesarg's avatar
      for-each-ref: `:short` format for `refname` · 7d66f21a
      Bert Wesarg authored
      Tries to shorten the refname to a non-ambiguous name.
      Szeder Gábor noticed that the git bash completion takes a
      tremendous amount of time to strip leading components from
      heads and tags refs (i.e. refs/heads, refs/tags, ...). He
      proposed a new atom called 'refbasename' which removes at
      most two leading components from the ref name.
      I myself, proposed a more dynamic solution, which strips off
      common leading components with the matched pattern.
      But the current bash solution and both proposals suffer from
      one mayor problem: ambiguous refs.
      A ref is ambiguous, if it resolves to more than one full refs.
      I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The
      (short) ref xyzzy can point to both refs.
      ( Note: Its irrelevant whether the referenced objects are the
        same or not. )
      This proposal solves this by checking for ambiguity of the
      shorten ref name.
      The shortening is done with the same rules for resolving refs
      but in the reverse order. The short name is checked if it
      resolves to a different ref.
      To continue the above example, the output would be like this:
      So, if you want just tags, xyzzy is not ambiguous, because it
      will resolve to a tag. If you need the heads you get a also
      a non-ambiguous short form of the ref.
      To integrate this new format into the bash completion to get
      only non-ambiguous refs is beyond the scope of this patch.
      Signed-off-by: Bert Wesarg's avatarBert Wesarg <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  16. 02 Sep, 2008 1 commit
  17. 06 Aug, 2008 1 commit
  18. 31 Jul, 2008 1 commit
  19. 05 Jul, 2008 1 commit
  20. 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]>
  21. 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::
      But AsciiDoc has the special form:
      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]>
  22. 06 Jun, 2008 1 commit
  23. 30 Sep, 2007 1 commit
    • Andy Parkins's avatar
      Make for-each-ref's grab_date() support per-atom formatting · d392e712
      Andy Parkins authored
      grab_date() gets an extra parameter - atomname; this extra parameter is
      checked to see if it has a ":<format>" extra component in it, and if so
      that "<format>" string is passed to parse_date_format() to produce an
      enum date_mode value which is then further passed to show_date().
      In short it allows the user of git-for-each-ref to do things like this:
       $ git-for-each-ref --format='%(taggerdate:default)' refs/tags/v1.5.2
       Sun May 20 00:30:42 2007 -0700
       $ git-for-each-ref --format='%(taggerdate:relative)' refs/tags/v1.5.2
       4 months ago
       $ git-for-each-ref --format='%(taggerdate:short)' refs/tags/v1.5.2
       $ git-for-each-ref --format='%(taggerdate:local)' refs/tags/v1.5.2
       Sun May 20 08:30:42 2007
       $ git-for-each-ref --format='%(taggerdate:iso8601)' refs/tags/v1.5.2
       2007-05-20 00:30:42 -0700
       $ git-for-each-ref --format='%(taggerdate:rfc2822)' refs/tags/v1.5.2
       Sun, 20 May 2007 00:30:42 -0700
      The default, when no ":<format>" is specified is ":default", leaving the
      existing behaviour unchanged.
      Signed-off-by: default avatarAndy Parkins <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  24. 19 May, 2007 1 commit
  25. 05 Feb, 2007 1 commit
  26. 28 Jan, 2007 1 commit
  27. 17 Jan, 2007 1 commit
  28. 28 Oct, 2006 2 commits
  29. 21 Sep, 2006 1 commit
  30. 16 Sep, 2006 1 commit