| Age | Commit message (Collapse) | Author |
|---|
|
"git log" family learned "--pretty=reference" that gives the name
of a commit in the format that is often used to refer to it in log
messages.
* dl/pretty-reference:
SubmittingPatches: use `--pretty=reference`
pretty: implement 'reference' format
pretty: add struct cmt_fmt_map::default_date_mode_type
pretty: provide short date format
t4205: cover `git log --reflog -z` blindspot
pretty.c: inline initalize format_context
revision: make get_revision_mark() return const pointer
completion: complete `tformat:` pretty format
SubmittingPatches: remove dq from commit reference
pretty-formats.txt: use generic terms for hash
SubmittingPatches: use generic terms for hash
|
|
The standard format for referencing other commits within some projects
(such as git.git) is the reference format. This is described in
Documentation/SubmittingPatches as
If you want to reference a previous commit in the history of a stable
branch, use the format "abbreviated hash (subject, date)", like this:
....
Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
noticed that ...
....
Since this format is so commonly used, standardize it as a pretty
format.
The tests that are implemented essentially show that the format-string
does not change in response to various log options. This is useful
because, for future developers, it shows that we've considered the
limitations of the "canned format-string" approach and we are fine with
them.
Based-on-a-patch-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Add the placeholders %as and %cs to format author date and committer
date, respectively, without the time part, like --date=short does, i.e.
like YYYY-MM-DD.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Since Git is planning on upgrading from SHA-1 to be more hash-agnostic,
replace specific references to SHA-1 with more generic terminology.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
In many projects the number of contributors is low enough that users know
each other and the full email address doesn't need to be displayed.
Displaying only the author's username saves a lot of columns on the screen.
Existing 'e/E' (as in "%ae" and "%aE") placeholders would show the
author's address as "prarit@redhat.com", which would waste columns to show
the same domain-part for all contributors when used in a project internal
to redhat. Introduce 'l/L' placeholders that strip '@' and domain part from
the e-mail address.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Move a closing backtick that was placed one character too soon.
Signed-off-by: Cameron Steffen <cam.steffen94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The %(trailers) formatter in "git log --format=..." now allows to
optionally pick trailers selectively by keyword, show only values,
etc.
* aw/pretty-trailers:
pretty: add support for separator option in %(trailers)
strbuf: separate callback for strbuf_expand:ing literals
pretty: add support for "valueonly" option in %(trailers)
pretty: allow showing specific trailers
pretty: single return path in %(trailers) handling
pretty: allow %(trailers) options with explicit value
doc: group pretty-format.txt placeholders descriptions
|
|
Doc update.
* kl/pretty-doc-markup-fix:
doc: prevent overflowing <code> tag in rendered HTML
|
|
Add an apparently missing back-tick to fix a multi-line <code> section
on https://git-scm.com/docs/git-log which seems to have been caused by
commit 18fb7ffc ("pretty: respect color settings [...]", 2017-07-13).
Signed-off-by: Katrin Leinweber <katrin.leinweber@uni-konstanz.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
By default trailer lines are terminated by linebreaks ('\n'). By
specifying the new 'separator' option they will instead be separated by
user provided string and have separator semantics rather than terminator
semantics. The separator string can contain the literal formatting codes
%n and %xNN allowing it to be things that are otherwise hard to type
such as %x00, or comma and end-parenthesis which would break parsing.
E.g:
$ git log --pretty='%(trailers:key=Reviewed-by,valueonly,separator=%x00)'
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
With the new "key=" option to %(trailers) it often makes little sense to
show the key, as it by definition already is knows which trailer is
printed there. This new "valueonly" option makes it omit the key when
printing trailers.
E.g.:
$ git show -s --pretty='%s%n%(trailers:key=Signed-off-by,valueonly)' aaaa88182
will show:
> upload-pack: fix broken if/else chain in config callback
> Jeff King <peff@peff.net>
> Junio C Hamano <gitster@pobox.com>
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Adds a new "key=X" option to "%(trailers)" which will cause it to only
print trailer lines which match any of the specified keys.
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
In addition to old %(trailers:only) it is now allowed to write
%(trailers:only=yes)
By itself this only gives (the not quite so useful) possibility to have
users change their mind in the middle of a formatting
string (%(trailers:only=true,only=false)). However, it gives users the
opportunity to override defaults from future options.
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Make it possible to write for example
git log --format="%H,%S"
where the %S at the end is a new placeholder that prints out the ref
(tag/branch) for each commit.
Using %d might seem like an alternative but it only shows the ref for the last
commit in the branch.
Signed-off-by: Issac Trotts <issactrotts@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The placeholders can be grouped into three kinds:
* literals
* affecting formatting of later placeholders
* expanding to information in commit
Also change the list to a definition list (using '::')
Signed-off-by: Anders Waldenborg <anders@0x63.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Obtain the primary key fingerprint off VALIDSIG status message,
and expose it via %GP format.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Support processing VALIDSIG status that provides additional information
for valid signatures. Use this information to propagate signing key
fingerprint and expose it via %GF pretty format. This format can be
used to build safer key verification systems that verify the key via
complete fingerprint rather than short/long identifier provided by %GK.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Docfix.
* mk/doc-pretty-fill:
docs/pretty-formats: fix typo '% <(<N>)' -> '%<|(<N>)'
|
|
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>
|
|
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>
|
|
"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
|
|
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>
|
|
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>
|
|
Doc update.
* ah/doc-pretty-color-auto-prefix:
doc: clarify syntax for %C(auto,...) in pretty formats
|
|
Doc update.
* ah/doc-pretty-color-auto-prefix:
doc: clarify syntax for %C(auto,...) in pretty formats
|
|
Doc update.
* sg/doc-pretty-formats:
docs/pretty-formats: stress that %- removes all preceding line-feeds
|
|
Doc update.
* sg/doc-pretty-formats:
docs/pretty-formats: stress that %- removes all preceding line-feeds
|
|
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>
|
|
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
A missing space messed up formatting of the `%(trailers)` format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
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>
|
|
Small doc update.
* rs/pretty-format-color-doc-fix:
pretty: fix document link for color specification
|
|
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
|
|
* rs/pretty-format-color-doc-fix:
pretty: fix document link for color specification
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
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>
|
|
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>
|
|
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
|
|
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* bc/asciidoc-pretty-formats-fix:
Documentation: fix misrender of pretty-formats in Asciidoctor
|
|
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>
|
|
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
|
|
"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
|
|
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>
|
