summaryrefslogtreecommitdiff
path: root/Documentation/pretty-options.txt
AgeCommit message (Collapse)AuthorFilesLines
2019-12-10Merge branch 'dl/pretty-reference'Libravatar Junio C Hamano1-1/+1
"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
2019-11-21pretty-options.txt: --notes accepts a ref instead of treeishLibravatar Denton Liu1-4/+4
Although `--notes=` accepts and handles a tree-ish just fine, it isn't a common use-case for users to pass in bare trees. By having "treeish", it makes it harder to click in users' minds that the argument here is the same type as the `notes.displayRef` configuration variable, for example. Change `treeish` to `ref` so that it will be easier for users to make this connection. Note that we don't completely lose the notion that `--notes=` can accept a tree-ish. In git-notes.txt, we have It is also permitted for a notes ref to point directly to a tree object, in which case the history of the notes can be read with `git log -p -g <refname>`. which means that a hardcore user who wants to take advantage of this obscure use-case will be able to infer the connection and not be completely left in the dark. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-20pretty: implement 'reference' formatLibravatar Denton Liu1-1/+1
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>
2016-06-27Merge branch 'tr/doc-tt'Libravatar Junio C Hamano1-2/+2
The documentation set has been updated so that literal commands, configuration variables and environment variables are consistently typeset in fixed-width font and bold in manpages. * tr/doc-tt: doc: change configuration variables format doc: more consistency in environment variables format doc: change environment variables format doc: clearer rule about formatting literals
2016-06-08doc: change configuration variables formatLibravatar Tom Russello1-2/+2
This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-13Merge branch 'lt/pretty-expand-tabs'Libravatar Junio C Hamano1-0/+14
When "git log" shows the log message indented by 4-spaces, the remainder of a line after a HT does not align in the way the author originally intended. The command now expands tabs by default in such a case, and allows the users to override it with a new option, '--no-expand-tabs'. * lt/pretty-expand-tabs: pretty: test --expand-tabs pretty: allow tweaking tabwidth in --expand-tabs pretty: enable --expand-tabs by default for selected pretty formats pretty: expand tabs in indented logs to make things line up properly
2016-03-30pretty: allow tweaking tabwidth in --expand-tabsLibravatar Junio C Hamano1-3/+6
When the local convention of the project is to use tab width that is not 8, it may make sense to allow "git log --expand-tabs=<n>" to tweak the output to match it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30pretty: enable --expand-tabs by default for selected pretty formatsLibravatar Junio C Hamano1-0/+6
"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats. Add --no-expand-tabs option to override the new default. The change alone breaks a test in t4201 that runs "git shortlog" on the output from "git log", and expects that the output from "git log" does not do such a tab expansion. Adjust the test to explicitly disable expand-tabs with --no-expand-tabs. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30pretty: expand tabs in indented logs to make things line up properlyLibravatar Linus Torvalds1-0/+5
A commit log message sometimes tries to line things up using tabs, assuming fixed-width font with the standard 8-place tab settings. Viewing such a commit however does not work well in "git log", as we indent the lines by prefixing 4 spaces in front of them. This should all line up: Column 1 Column 2 -------- -------- A B ABCD EFGH SPACES Instead of Tabs Even with multi-byte UTF8 characters: Column 1 Column 2 -------- -------- Ä B åäö 100 A Møøse once bit my sister.. Tab-expand the lines in "git log --expand-tabs" output before prefixing 4 spaces. This is based on the patch by Linus Torvalds, but at this step, we require an explicit command line option to enable the behaviour. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12notes: allow treeish expressions as notes refLibravatar Mike Hommey1-4/+4
init_notes() is the main point of entry to the notes API. It ensures that the input can be used as ref, because it needs a ref to update to store notes tree after modifying it. There however are many use cases where notes tree is only read, e.g. "git log --notes=...". Any notes-shaped treeish could be used for such purpose, but it is not allowed due to existing restriction. Allow treeish expressions to be used in the case the notes tree is going to be used without write "permissions". Add a flag to distinguish whether the notes tree is intended to be used read-only, or will be updated. With this change, operations that use notes read-only can be fed any notes-shaped tree-ish can be used, e.g. git log --notes=notes@{1}. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-22notes: correct documentation of DWIMery for notes referencesLibravatar Jacob Keller1-2/+3
expand_notes_ref is used by --ref from git-notes(1) and --notes from the git log to find the full refname of a notes reference. Previously the documentation of these options was not clear about what sorts of expansions would be performed. Fix the documentation to clearly and accurately describe the behavior of the expansions. Add a test for this expansion when using git notes get-ref in order to prevent future patches from changing this behavior. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> 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-07-10Merge branch 'jk/pretty-encoding-doc'Libravatar Junio C Hamano1-1/+4
Doc update. * jk/pretty-encoding-doc: docs: clarify that --encoding can produce invalid sequences
2015-06-17docs: clarify that --encoding can produce invalid sequencesLibravatar Jeff King1-1/+4
In the common case that the commit encoding matches the output encoding, we do not touch the buffer at all, which makes things much more efficient. But it might be unclear to a consumer that we will pass through bogus sequences. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-15"log --pretty" documentation: do not forget "tformat:"Libravatar Junio C Hamano1-3/+7
We forgot to list "tformat:<string>" when enumerating possible values that "--pretty=<format>" can take. It was not described that "--pretty='string with %s placeholder'" that is not understood is DWIMmed as "--pretty=tformat:<that string>". Further, it was unclear what "When omitted, defaults to 'medium'" was meant. Is it "When --pretty=<something> was not given at all", or is it "When --pretty is given without =<something>"? Clarify that it is the latter. 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-08-05log doc: the argument to --encoding is not optionalLibravatar Jonathan Nieder1-1/+1
$ git log --encoding fatal: Option '--encoding' requires a value $ git rev-list --encoding fatal: Option '--encoding' requires a value The argument to --encoding has always been mandatory. Unfortunately manpages like git-rev-list(1), git-log(1), and git-show(1) have described the option's syntax as "--encoding[=<encoding>]" since it was first documented. Clarify by removing the extra brackets. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Documentation: Document signature showing optionsLibravatar Stephen Boyd1-0/+4
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>
2011-05-18Add log.abbrevCommit config variableLibravatar Jay Soffian1-0/+5
Add log.abbrevCommit config variable as a convenience for users who often use --abbrev-commit with git log and friends. Allow the option to be overridden with --no-abbrev-commit. Per 635530a2fc and 4f62c2bc57, the config variable is ignored when log is given "--pretty=raw". (Also, a drive-by spelling correction in git log's short help.) Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30log/pretty-options: Document --[no-]notes and deprecate old notes optionsLibravatar Johan Herland1-10/+25
Document the behavior or the new --notes, --notes=<ref> and --no-notes options, and list --show-notes[=<ref>] and --[no-]standard-notes options as deprecated. Signed-off-by: Johan Herland <johan@herland.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-08Remove stray quotes in --pretty and --format documentationLibravatar Štěpán Němec1-2/+2
Quotes (for emphasis) are used in option explanations, not the headings. Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-05pretty-options.txt: match --format's documentation with implementation.Libravatar Matthieu Moy1-1/+1
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02Documentation/pretty-{formats,options}: better reference for "format:<string>"Libravatar Nazri Ramliy1-2/+3
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-03-12Support showing notes from more than one notes treeLibravatar Thomas Rast1-1/+10
With this patch, you can set notes.displayRef to a glob that points at your favourite notes refs, e.g., [notes] displayRef = refs/notes/* Then git-log and friends will show notes from all trees. Thanks to Junio C Hamano for lots of feedback, which greatly influenced the design of the entire series and this commit in particular. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-21Fix "log --oneline" not to show notesLibravatar Junio C Hamano1-2/+2
This option should be treated pretty much the same as --format="%h %s". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Fix "log" family not to be too agressive about showing notesLibravatar Junio C Hamano1-0/+8
Giving "Notes" information in the default output format of "log" and "show" is a sensible progress (the user has asked for it by having the notes), but for some commands (e.g. "format-patch") spewing notes into the formatted commit log message without being asked is too aggressive. Enable notes output only for "log", "show", "whatchanged" by default and only when the user didn't ask any specific --pretty/--format from the command line; users can explicitly override this default with --show-notes and --no-notes option. Parts of tests are taken from Jeff King's fix. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-24Add --oneline that is a synonym to "--pretty=oneline --abbrev-commit"Libravatar Nanako Shiraishi1-0/+4
These two are often used together but are too long to type. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-24Add --format that is a synonym to --prettyLibravatar Nanako Shiraishi1-0/+1
Some people prefer to call the pretty-print styles "format", and get annoyed to see "git log --format=short" fail. Introduce it as a synonym to --pretty so that both can be used. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-13Fix Documentation typos surrounding the word 'handful'.Libravatar Jon Loeliger1-1/+1
Some instances replaced by "handful of", others use the word "few", a couple get a slight rewording. Signed-off-by: Jon Loeliger <jdl@freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-05log/show/whatchanged: introduce format.pretty configurationLibravatar Denis Cheng1-0/+3
When running log/show/whatchanged from the command line, the user may want to use a preferred format without having to pass --pretty=<fmt> option every time from the command line. This teaches these three commands to honor a new configuration variable, format.pretty. The --pretty option given from the command line will override the configured format. The earlier patch fixed the in-tree callers that run these commands for purposes other than showing the output directly to the end user (the only other in-tree caller is "git bisect visualize", whose output directly goes to the end user and should be affected by this patch). Similar fixes will be needed for end-user scripts that parse the output from these commands and expect them to be in the default pretty format. Signed-off-by: Denis Cheng <crquan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-25pretty-options.txt: tiny doc fixLibravatar Jim Meyering1-2/+2
Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-16Document git log --abbrev-commit, as a kind of pretty optionLibravatar Jakub Narebski1-0/+9
Documentation taken from paraphrased description of "--abbrev[=<n>]" diff option, and from description of commit 5c51c985 introducing this option. Note that to change number of digits one must use "--abbrev=<n>", which affects [also] diff output. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
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: Junio C Hamano <gitster@pobox.com>
2007-05-13Documentation: Split description of pretty formats of commit logLibravatar Jakub Narebski1-0/+14
Split description of pretty formats into list of pretty options (--pretty and --encoding) in new file Documentation/pretty-options.txt and description of formats itself as a separate "PRETTY FORMATS" section in pretty-formats.txt While at it correct formatting a bit, to be better laid out in the resulting manpages: git-rev-list(1), git-show(1), git-log(1) and git-diff-tree(1). Those manpages now include pretty options in the same place as it was before, and description of formats just after all options. Inspired by the split into two filesdocumentation for merge strategies: Documentation/merge-options.txt and Documentation/merge-strategies.txt Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>