summaryrefslogtreecommitdiff
path: root/Documentation/pretty-formats.txt
AgeCommit message (Collapse)AuthorFilesLines
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-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'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-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-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>
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-3/+3
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 <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-16pretty: give placeholders to reflog identityLibravatar Jeff King1-0/+4
When doing a reflog walk, you can get some information about the reflog (such as the subject line), but not the identity information (i.e., name and email). Let's make those available, mimicing the options for author and committer identity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-16pretty: Introduce ' ' modifier to add space if non-emptyLibravatar Michael J Gruber1-0/+4
We have the '+' modifiier which helps combine format specifiers which may possibly be empty, e.g. '%s%+b%n'. Introduce an analogous ' ' (space) modifier which adds a space before non-empty items. This helps assemble "one line type" format specifiers. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13Merge branch 'wp/pretty-enhancement'Libravatar Junio C Hamano1-1/+6
* wp/pretty-enhancement: pretty: initialize new cmt_fmt_map to 0 pretty: add aliases for pretty formats pretty: add infrastructure for commit format aliases pretty: make it easier to add new formats
2010-06-02Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: git-compat-util.h: use apparently more common __sgi macro to detect SGI IRIX Documentation: A...B shortcut for checkout and rebase Documentation/pretty-{formats,options}: better reference for "format:<string>"
2010-06-02Documentation/pretty-{formats,options}: better reference for "format:<string>"Libravatar Nazri Ramliy1-2/+2
In "git help log" (and friends) it's not easy to find the possible placeholder for <string> for the "--pretty=format:<string>" option to git log. This patch makes the placeholder easier to find by adding a reference to the "PRETTY FORMATS" section and repeating the "format:<string>" phrase. Signed-off-by: Nazri Ramliy <ayiehere@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-03pretty: add aliases for pretty formatsLibravatar Will Palmer1-1/+6
previously the only ways to alias a --pretty format within git were either to set the format as your default format (via the format.pretty configuration variable), or by using a regular git alias. This left the definition of more complicated formats to the realm of "builtin or nothing", with user-defined formats usually being reserved for quick one-offs. Here we allow user-defined formats to enjoy more or less the same benefits of builtins. By defining pretty.myalias, "myalias" can be used in place of whatever would normally come after --pretty=. This can be a format:, tformat:, raw (ie, defaulting to tformat), or the name of another builtin or user-defined pretty format. Signed-off-by: Will Palmer <wmpalmer@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-05Add `%B' in format strings for raw commit body in `git log' and friendsLibravatar Eli Barzilay1-0/+1
Also update the documentation text and add a test. Signed-off-by: Eli Barzilay <eli@barzilay.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-14strbuf_expand: convert "%%" to "%"Libravatar Jeff King1-0/+1
The only way to safely quote arbitrary text in a pretty-print user format is to replace instances of "%" with "%x25". This is slightly unreadable, and many users would expect "%%" to produce a single "%", as that is what printf format specifiers do. This patch converts "%%" to "%" for all users of strbuf_expand(): (1) git-daemon interpolated paths (2) pretty-print user formats (3) merge driver command lines Case (1) was already doing the conversion itself outside of strbuf_expand(). Case (2) is the intended beneficiary of this patch. Case (3) users probably won't notice, but as this is user-facing behavior, consistently providing the quoting mechanism makes sense. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>