summaryrefslogtreecommitdiff
path: root/Documentation/pretty-formats.txt
AgeCommit message (Collapse)AuthorFilesLines
2018-03-08Merge branch 'mk/doc-pretty-fill'Libravatar Junio C Hamano1-1/+1
Docfix. * mk/doc-pretty-fill: docs/pretty-formats: fix typo '% <(<N>)' -> '%<|(<N>)'
2018-02-27docs/pretty-formats: fix typo '% <(<N>)' -> '%<|(<N>)'Libravatar Mårten Kongstad1-1/+1
Remove erroneous space between % and < in '% <(<N>)'. Signed-off-by: Mårten Kongstad <marten.kongstad@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08docs/pretty-formats: mention commas in %(trailers) syntaxLibravatar Jeff King1-5/+7
Commit 84ff053d47 (pretty.c: delimit "%(trailers)" arguments with ",", 2017-10-01) switched the syntax of the trailers placeholder, but forgot to update the documentation in pretty-formats.txt. There's no need to mention the old syntax; it was never in a released version of Git. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-26Merge branch 'jk/trailers-parse'Libravatar Junio C Hamano1-1/+4
"git interpret-trailers" has been taught a "--parse" and a few other options to make it easier for scripts to grab existing trailer lines from a commit log message. * jk/trailers-parse: doc/interpret-trailers: fix "the this" typo pretty: support normalization options for %(trailers) t4205: refactor %(trailers) tests pretty: move trailer formatting to trailer.c interpret-trailers: add --parse convenience option interpret-trailers: add an option to unfold values interpret-trailers: add an option to show only existing trailers interpret-trailers: add an option to show only the trailers trailer: put process_trailers() options into a struct
2017-08-15pretty: support normalization options for %(trailers)Libravatar Jeff King1-1/+4
The interpret-trailers command recently learned some options to make its output easier to parse (for a caller whose only interested in picking out the trailer values). But it's not very efficient for asking for the trailers of many commits in a single invocation. We already have "%(trailers)" to do that, but it doesn't know about unfolding or omitting non-trailers. Let's plumb those options through, so you can have the best of both. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13pretty: respect color settings for %C placeholdersLibravatar Jeff King1-7/+11
The color placeholders have traditionally been unconditional, showing colors even when git is not otherwise configured to do so. This was not so bad for their original use, which was on the command-line (and the user could decide at that moment whether to add colors or not). But these days we have configured formats via pretty.*, and those should operate correctly in multiple contexts. In 3082517 (log --format: teach %C(auto,black) to respect color config, 2012-12-17), we gave an extended placeholder that could be used to accomplish this. But it's rather clunky to use, because you have to specify it individually for each color (and their matching resets) in the format. We shied away from just switching the default to auto, because it is technically breaking backwards compatibility. However, there's not really a use case for unconditional colors. The most plausible reason you would want them is to redirect "git log" output to a file. But there, the right answer is --color=always, as it does the right thing both with custom user-format colors and git-generated colors. So let's switch to the more useful default. In the off-chance that somebody really does find a use for unconditional colors without wanting to enable the rest of git's colors, we provide a new %C(always,...) to enable the old behavior. And we can remind them of --color=always in the documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10Merge branch 'ah/doc-pretty-color-auto-prefix' into maintLibravatar Junio C Hamano1-5/+6
Doc update. * ah/doc-pretty-color-auto-prefix: doc: clarify syntax for %C(auto,...) in pretty formats
2017-06-30Merge branch 'ah/doc-pretty-color-auto-prefix'Libravatar Junio C Hamano1-5/+6
Doc update. * ah/doc-pretty-color-auto-prefix: doc: clarify syntax for %C(auto,...) in pretty formats
2017-06-24Merge branch 'sg/doc-pretty-formats' into maintLibravatar Junio C Hamano1-2/+2
Doc update. * sg/doc-pretty-formats: docs/pretty-formats: stress that %- removes all preceding line-feeds
2017-06-24Merge branch 'sg/doc-pretty-formats'Libravatar Junio C Hamano1-2/+2
Doc update. * sg/doc-pretty-formats: docs/pretty-formats: stress that %- removes all preceding line-feeds
2017-06-24doc: clarify syntax for %C(auto,...) in pretty formatsLibravatar Andreas Heiduk1-5/+6
The manual correctly describes the syntax with `auto,` but the trailing `,` is hard to spot in a terminal. The HTML format does not have this problem. Adding an example helps both worlds. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15docs/pretty-formats: stress that %- removes all preceding line-feedsLibravatar SZEDER Gábor1-2/+2
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-23Documentation: fix formatting typo in pretty-formats.txtLibravatar Andreas Heiduk1-1/+1
A missing space messed up formatting of the `%(trailers)` format. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-11pretty: add %(trailers) format for displaying trailers of a commit messageLibravatar Jacob Keller1-0/+2
Recent patches have expanded on the trailers.c code and we have the builtin commant git-interpret-trailers which can be used to add or modify trailer lines. However, there is no easy way to simply display the trailers of a commit message. Add support for %(trailers) format modifier which will use the trailer_info_get() calls to read trailers in an identical way as git interpret-trailers does. Use a long format option instead of a short name so that future work can more easily unify ref-filter and pretty formats. Add documentation and tests for the same. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-28Merge branch 'rs/pretty-format-color-doc-fix' into maintLibravatar Junio C Hamano1-1/+2
Small doc update. * rs/pretty-format-color-doc-fix: pretty: fix document link for color specification
2016-10-26Merge branch 'mg/gpg-richer-status'Libravatar Junio C Hamano1-2/+8
The GPG verification status shown in "%G?" pretty format specifier was not rich enough to differentiate a signature made by an expired key, a signature made by a revoked key, etc. New output letters have been assigned to express them. * mg/gpg-richer-status: gpg-interface: use more status letters
2016-10-17Merge branch 'rs/pretty-format-color-doc-fix'Libravatar Junio C Hamano1-1/+2
* rs/pretty-format-color-doc-fix: pretty: fix document link for color specification
2016-10-12gpg-interface: use more status lettersLibravatar Michael J Gruber1-2/+8
According to gpg2's doc/DETAILS: For each signature only one of the codes GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted. gpg1 ("classic") behaves the same (although doc/DETAILS differs). Currently, we parse gpg's status output for GOODSIG, BADSIG and trust information and translate that into status codes G, B, U, N for the %G? format specifier. git-verify-* returns success in the GOODSIG case only. This is somewhat in disagreement with gpg, which considers the first 5 of the 6 above as VALIDSIG, but we err on the very safe side. Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG, EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information about the absence of a 'G' on first glance. Requested-by: Alex <agrambot@gmail.com> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-11pretty: fix document link for color specificationLibravatar René Scharfe1-1/+2
Helped-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-19Merge branch 'po/range-doc' into maintLibravatar Junio C Hamano1-1/+1
Clarify various ways to specify the "revision ranges" in the documentation. * po/range-doc: doc: revisions: sort examples and fix alignment of the unchanged doc: revisions: show revision expansion in examples doc: revisions - clarify reachability examples doc: revisions - define `reachable` doc: gitrevisions - clarify 'latter case' is revision walk doc: gitrevisions - use 'reachable' in page description doc: revisions: single vs multi-parent notation comparison doc: revisions: extra clarification of <rev>^! notation effects doc: revisions: give headings for the two and three dot notations doc: show the actual left, right, and boundary marks doc: revisions - name the left and right sides doc: use 'symmetric difference' consistently
2016-09-08Merge branch 'po/range-doc'Libravatar Junio C Hamano1-1/+1
Clarify various ways to specify the "revision ranges" in the documentation. * po/range-doc: doc: revisions: sort examples and fix alignment of the unchanged doc: revisions: show revision expansion in examples doc: revisions - clarify reachability examples doc: revisions - define `reachable` doc: gitrevisions - clarify 'latter case' is revision walk doc: gitrevisions - use 'reachable' in page description doc: revisions: single vs multi-parent notation comparison doc: revisions: extra clarification of <rev>^! notation effects doc: revisions: give headings for the two and three dot notations doc: show the actual left, right, and boundary marks doc: revisions - name the left and right sides doc: use 'symmetric difference' consistently
2016-07-22doc/pretty-formats: explain shortening of %gdLibravatar Jeff King1-3/+6
The actual shortening rules aren't that interesting and probably not worth getting into (I gloss over them here as "shortened for human readability"). But the fact that %gD shows whatever you gave on the command line is subtle and worth mentioning. Since most people will feed a shortened refname in the first place, it otherwise makes it hard to understand the difference between the two. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-22doc/pretty-formats: describe index/time formats for %gdLibravatar Jeff King1-2/+5
The "reflog selector" format changes based on a series of heuristics, and that applies equally to both stock "log -g" output, as well as "--format=%gd". The documentation for "%gd" doesn't cover this. Let's mention the multiple formats and refer the user back to the "-g" section for the complete rules. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-20doc: show the actual left, right, and boundary marksLibravatar Philip Oakley1-1/+1
Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13Documentation: clarify signature verificationLibravatar Keller Fuchs1-2/+2
Clarify that "merge --verify-signatures" checks the signature on the tip commit of the history being merged. Uniformise the vocabulary used wrt. key/signature validity with OpenPGP: - a signature is valid if made by a key with a valid uid; - in the default trust-model, a uid is valid if signed by a trusted key; - a key is trusted if the (local) user set a trust level for it. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Keller Fuchs <KellerFuchs@hashbang.sh> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-24rev-list: make it obvious that we do not support notesLibravatar Jeff King1-0/+2
The rev-list command does not have the internal infrastructure to display notes. Running: git rev-list --notes HEAD will silently ignore the "--notes" option. Running: git rev-list --notes --grep=. HEAD will crash on an assert. Running: git rev-list --format=%N HEAD will place a literal "%N" in the output (it does not even expand to an empty string). Let's have rev-list tell the user that it cannot fill the user's request, rather than silently producing wrong data. Likewise, let's remove mention of the notes options from the rev-list documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01Merge branch 'mm/log-format-raw-doc'Libravatar Junio C Hamano1-1/+4
Clarify that "log --raw" and "log --format=raw" are unrelated concepts. * mm/log-format-raw-doc: Documentation/log: clarify sha1 non-abbreviation in log --raw Documentation/log: clarify what --raw means
2015-05-20Documentation/log: clarify sha1 non-abbreviation in log --rawLibravatar Matthieu Moy1-1/+4
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-14Merge branch 'bc/asciidoc-pretty-formats-fix'Libravatar Junio C Hamano1-1/+1
* bc/asciidoc-pretty-formats-fix: Documentation: fix misrender of pretty-formats in Asciidoctor
2014-10-08Documentation: fix misrender of pretty-formats in AsciidoctorLibravatar brian m. carlson1-1/+1
Neither the AsciiDoc nor the Asciidoctor documentation specify whether the same number of delimiter characters must be used to end a block as to begin it, although both sets of documentation show exactly matching pairs. AsciiDoc allows mismatches, but AsciiDoctor apparently does not. Adjust the pretty formats documentation to use matching pairs to prevent a misrendering where the remainder of the document was rendered as a listing block. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Merge branch 'hj/pretty-naked-decoration'Libravatar Junio C Hamano1-2/+4
The pretty-format specifier "%d", which expanded to " (tagname)" for a tagged commit, gained a cousin "%D" that just gives the "tagname" without frills. * hj/pretty-naked-decoration: pretty: add %D format specifier
2014-09-19Merge branch 'bb/date-iso-strict'Libravatar Junio C Hamano1-2/+4
"log --date=iso" uses a slight variant of ISO 8601 format that is made more human readable. A new "--date=iso-strict" option gives datetime output that is more strictly conformant. * bb/date-iso-strict: pretty: provide a strict ISO 8601 date format
2014-09-18pretty: add %D format specifierLibravatar Harry Jeffery1-2/+4
Add a new format specifier, '%D' that is identical in behaviour to '%d', except that it does not include the ' (' prefix or ')' suffix provided by '%d'. Signed-off-by: Harry Jeffery <harry@exec64.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-29pretty: provide a strict ISO 8601 date formatLibravatar Beat Bolli1-2/+4
Git's "ISO" date format does not really conform to the ISO 8601 standard due to small differences, and it cannot be parsed by ISO 8601-only parsers, e.g. those of XML toolchains. The output from "--date=iso" deviates from ISO 8601 in these ways: - a space instead of the `T` date/time delimiter - a space between time and time zone - no colon between hours and minutes of the time zone Add a strict ISO 8601 date format for displaying committer and author dates. Use the '%aI' and '%cI' format specifiers and add '--date=iso-strict' or '--date=iso8601-strict' date format names. See http://thread.gmane.org/gmane.comp.version-control.git/255879 and http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585 for discussion. Signed-off-by: Beat Bolli <bbolli@ewanet.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-21pretty: note that %cd respects the --date= optionLibravatar Thomas Braun1-1/+1
Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31Documentation: fix misuses of "nor"Libravatar Justin Lebar1-1/+1
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-23Merge branch 'nd/pretty-formats'Libravatar Junio C Hamano1-7/+28
pretty-printing body of the commit that is stored in non UTF-8 encoding did not work well. The early part of this series fixes it. And then it adds %C(auto) specifier that turns the coloring on when we are emitting to the terminal, and adds column-aligning format directives. * nd/pretty-formats: pretty: support %>> that steal trailing spaces pretty: support truncating in %>, %< and %>< pretty: support padding placeholders, %< %> and %>< pretty: add %C(auto) for auto-coloring pretty: split color parsing into a separate function pretty: two phase conversion for non utf-8 commits utf8.c: add reencode_string_len() that can handle NULs in string utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences utf8.c: move display_mode_esc_sequence_len() for use by other functions pretty: share code between format_decoration and show_decorations pretty-formats.txt: wrap long lines pretty: get the correct encoding for --pretty:format=%e pretty: save commit encoding from logmsg_reencode if the caller needs it
2013-04-21Merge branch 'ta/glossary'Libravatar Junio C Hamano1-1/+1
* ta/glossary: glossary: improve definitions of refspec and pathspec The name of the hash function is "SHA-1", not "SHA1" glossary: improve description of SHA-1 related topics glossary: remove outdated/misleading/irrelevant entries
2013-04-18pretty: support %>> that steal trailing spacesLibravatar Nguyễn Thái Ngọc Duy1-1/+4
This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not use up all 100 columns and %an needs more than 20 columns. By replacing %>(20) with %>>(20), %an can steal spaces from %s. %>> understands escape sequences, so %Cred does not stop it from stealing spaces in %<(100). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty: support truncating in %>, %< and %><Libravatar Nguyễn Thái Ngọc Duy1-2/+5
%>(N,trunc) truncates the right part after N columns and replace the last two letters with "..". ltrunc does the same on the left. mtrunc cuts the middle out. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty: support padding placeholders, %< %> and %><Libravatar Nguyễn Thái Ngọc Duy1-0/+8
Either %<, %> or %>< standing before a placeholder specifies how many columns (at least as the placeholder can exceed it) it takes. Each differs on how spaces are padded: %< pads on the right (aka left alignment) %> pads on the left (aka right alignment) %>< pads both ways equally (aka centered) The (<N>) follows them, e.g. `%<(100)', to specify the number of columns the next placeholder takes. However, if '|' stands before (<N>), e.g. `%>|(100)', then the number of columns is calculated so that it reaches the Nth column on screen. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty: add %C(auto) for auto-coloringLibravatar Nguyễn Thái Ngọc Duy1-1/+2
This is not simply convenient over %C(auto,xxx). Some placeholders (actually only one, %d) do multi coloring and we can't emit a multiple colors with %C(auto,xxx). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty-formats.txt: wrap long linesLibravatar Nguyễn Thái Ngọc Duy1-6/+12
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15The name of the hash function is "SHA-1", not "SHA1"Libravatar Thomas Ackermann1-1/+1
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-03Merge branch 'mg/gpg-interface-using-status' into maintLibravatar Junio C Hamano1-0/+1
Verification of signed tags were not done correctly when not in C or en/US locale. * mg/gpg-interface-using-status: pretty: make %GK output the signing key for signed commits pretty: parse the gpg status lines rather than the output gpg_interface: allow to request status return log-tree: rely upon the check in the gpg_interface gpg-interface: check good signature in a reliable way
2013-03-31pretty printing: extend %G? to include 'N' and 'U'Libravatar Sebastian Götte1-1/+2
Expand %G? in pretty format strings to 'N' in case of no GPG signature and 'U' in case of a good but untrusted GPG signature in addition to the previous 'G'ood and 'B'ad. This eases writing anyting parsing git-log output. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-21Merge branch 'mg/gpg-interface-using-status'Libravatar Junio C Hamano1-0/+1
Call "gpg" using the right API when validating the signature on tags. * mg/gpg-interface-using-status: pretty: make %GK output the signing key for signed commits pretty: parse the gpg status lines rather than the output gpg_interface: allow to request status return log-tree: rely upon the check in the gpg_interface gpg-interface: check good signature in a reliable way
2013-02-14pretty: make %GK output the signing key for signed commitsLibravatar Michael J Gruber1-0/+1
In order to employ signed keys in an automated way it is absolutely necessary to check which keys the signatures come from. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-17log --format: teach %C(auto,black) to respect color configLibravatar Junio C Hamano1-1/+5
Traditionally, %C(color attr) always emitted the ANSI color sequence; it was up to the scripts that wanted to conditionally color their output to omit %C(...) specifier when they do not want colors. Optionally allow "auto," to be prefixed to the color, so that the output is colored iff we would color regular "log" output (e.g., taking into account color.* and --color command line options). Tests and pretty_context bits by Jeff King <peff@peff.net>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Documentation: Document signature showing optionsLibravatar Stephen Boyd1-0/+3
The pretty formats for GPG signatures were introduced but never documented. Use the documentation from the commit that introduced them. Do the same for the --show-signature option added to git log and friends. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>