summaryrefslogtreecommitdiff
path: root/t/t4205-log-pretty-formats.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-10-02t4205: unfold across multiple linesLibravatar Taylor Blau1-1/+1
Tests in t4205 test the following: git log --format='%(trailers:unfold)' ... By ensuring the multi-line trailers are unfolded back onto the same line. t4205 only includes tests for 2-line trailers, but `unfold()` will fail for folded trailers on 3 or more lines. In preparation for adding subsequent tests in t6300 that test similar behavior in `git-for-each-ref(1)`, let's harden t4205 (and make it consistent with the changes in t6300) by ensuring that 3 or more line folded trailers are unfolded correctly. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02pretty.c: delimit "%(trailers)" arguments with ","Libravatar Taylor Blau1-2/+2
In preparation for adding consistent "%(trailers)" atom options to `git-for-each-ref(1)`'s "--format" argument, change "%(trailers)" in pretty.c to separate sub-arguments with a ",", instead of a ":". Multiple sub-arguments are given either as "%(trailers:unfold,only)" or "%(trailers:only,unfold)". This change disambiguates between "top-level" arguments, and arguments given to the trailers atom itself. It is consistent with the behavior of "%(upstream)" and "%(push)" atoms. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15pretty: support normalization options for %(trailers)Libravatar Jeff King1-0/+33
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-08-15t4205: refactor %(trailers) testsLibravatar Jeff King1-8/+12
We currently have one test for %(trailers). In preparation for more, let's refactor a few bits: - move the commit creation to its own setup step so it can be reused by multiple tests - add a trailer with whitespace continuation (to confirm that it is left untouched) - fix the sample text which claims the placeholder is %bT. This was switched long ago to %(trailers) - replace one "cat" with an "echo" when generating the expected output. This saves a process (and sets a better pattern for future tests to follow). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-11tests: fix tests broken under GETTEXT_POISON=YesPleaseLibravatar Ævar Arnfjörð Bjarmason1-2/+2
The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on the list ("[BUG] test suite broken with GETTEXT_POISON=YesPlease", [1]) asking whether this mode was useful at all anymore. At least one person occasionally uses it, and Lars Schneider offered to change one of the the Travis builds to run in this mode, so fix up the failing ones. My test setup runs most of the tests, with the notable exception of skipping all the p4 tests, so it's possible that there's still some lurking regressions I haven't fixed. 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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/+26
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-07-27t4205: indent here documentsLibravatar Jeff King1-196/+196
Our usual style in the test scripts is to indent here documents with tabs, and use "<<-" to strip the tabs. The result is easier to read. This old test script did not do so in its inception, and further tests added onto it followed the local style. Let's bring it in line with our usual style. Some of the tests actually care quite a bit about whitespace, but none of them do so at the beginning of the line (because they use things like qz_to_tab_space to avoid depending on the literal whitespace), so we can do a fairly mechanical conversion. Most of the here-docs also use interpolation, so they have been left as "<<-EOF". In a few cases, though, where interpolation was not in use, I've converted them to "<<-\EOF" to match our usual "don't interpolate unless you need to" style. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-27t4205: drop top-level &&-chainingLibravatar Jeff King1-2/+4
The test currently does something like: do_one() && do_two() && test_expect_success ... We generally avoid performing actions at the top-level of the script (outside of a test_expect block) for two reasons: 1. The test harness is not checking and reporting if they fail. 2. Their output is not handled correctly (not hidden by default, nor shown with "-v"). Using &&-chains seems like it should help with (1), but it doesn't. If either of the commands fails, we simply skip running the follow-on test entirely, and the test harness has no idea. We can fix this by pushing that setup into its own block. It _could_ go into the following test block, but since the result in this case is used by multiple tests, it's more clear to mark it explicitly as a distinct setup step. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty.c: support <direction>|(<negative number>) formsLibravatar Nguyễn Thái Ngọc Duy1-0/+33
%>|(num), %><|(num) and %<|(num), where num is a positive number, sets a fixed column from the screen's left border. There is no way for us to specifiy a column relative to the right border, which is useful when you want to make use of all terminal space (on big screens). Use negative num for that. Inspired by Go's array syntax (*). (*) I know Python has this first (or before Go, at least) but the idea didn't occur to me until I learned Go. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-16pretty: pass graph width to pretty formatting for use in '%>|(N)'Libravatar Josef Kufner1-0/+24
Pass graph width to pretty formatting, to make N in '%>|(N)' include columns consumed by graph rendered when --graph option is in use. For example, in the output of git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' this change will make all commit hashes align at 20th column from the edge of the terminal, not from the edge of the graph. Signed-off-by: Josef Kufner <josef@kufner.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-29Merge branch 'hj/pretty-naked-decoration'Libravatar Junio C Hamano1-0/+11
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-0/+8
"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-0/+11
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-09-09Merge branch 'nd/strbuf-utf8-replace'Libravatar Junio C Hamano1-0/+7
* nd/strbuf-utf8-replace: utf8.c: fix strbuf_utf8_replace() consuming data beyond input string
2014-08-29pretty: provide a strict ISO 8601 date formatLibravatar Beat Bolli1-0/+8
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-11utf8.c: fix strbuf_utf8_replace() consuming data beyond input stringLibravatar Nguyễn Thái Ngọc Duy1-0/+7
The main loop in strbuf_utf8_replace() could summed up as: while ('src' is still valid) { 1) advance 'src' to copy ANSI escape sequences 2) advance 'src' to copy/replace visible characters } The problem is after #1, 'src' may have reached the end of the string (so 'src' points to NUL) and #2 will continue to copy that NUL as if it's a normal character. Because the output is stored in a strbuf, this NUL accounted in the 'len' field as well. Check after #1 and break the loop if necessary. The test does not look obvious, but the combination of %>>() should make a call trace like this show_log() pretty_print_commit() format_commit_message() strbuf_expand() format_commit_item() format_and_pad_commit() strbuf_utf8_replace() where %C(auto)%d would insert a color reset escape sequence in the end of the string given to strbuf_utf8_replace() and show_log() uses fwrite() to send everything to stdout (including the incorrect NUL inserted by strbuf_utf8_replace) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-15tests: do not pass iso8859-1 encoded parameterLibravatar Pat Thoyts1-1/+1
git commit -m with some iso8859-1 encoded stuff is doomed to fail in MinGW, because Windows don't let you pass encoded bytes to a process (CreateProcessW always takes a UTF-16LE encoded string). It is safe to pass the iso8859-1 message using a file or a pipe. Thanks-to: Karsten Blees <blees@dcon.de> Author: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21pretty.c: format string with truncate respects logOutputEncodingLibravatar Alexey Shumkin1-4/+4
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given length with an appropriate padding. This works for non-ASCII texts when i18n.logOutputEncoding is UTF-8 only (independently of a printed commit message encoding) but does not work when i18n.logOutputEncoding is NOT UTF-8. In 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19) 'format_commit_item' function assumes commit message to be in UTF-8. And that was so until ecaee80 (pretty: --format output should honor logOutputEncoding, 2013-06-26) where conversion to logOutputEncoding was added before calling 'format_commit_message'. Correct this by converting a commit message to UTF-8 first (as it assumed in 7e77df3 (pretty: two phase conversion for non utf-8 commits, 2013-04-19)). Only after that convert a commit message to an actual logOutputEncoding. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4205, t6006: add tests that fail with i18n.logOutputEncoding setLibravatar Alexey Shumkin1-0/+140
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given length with an appropriate padding. This works for non-ASCII texts when i18n.logOutputEncoding is UTF-8 only (independently of a printed commit message encoding) but does not work when i18n.logOutputEncoding is NOT UTF-8. There were no breakages as far as were no tests for the case when both a commit message and logOutputEncoding are not UTF-8. Add failing tests for that which will be fixed in the next patch. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4205 (log-pretty-format): use `tformat` rather than `format`Libravatar Alexey Shumkin1-39/+13
Use `tformat` to avoid using of `echo` to complete end of line. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21t4041, t4205, t6006, t7102: don't hardcode tested encoding valueLibravatar Alexey Shumkin1-4/+7
The tested encoding is always available in a variable. Use it instead of hardcoding. Also, to be in line with other tests use ISO8859-1 (uppercase) rather then iso8859-1. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-3/+11
The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. That was introduced in a742f2a (t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was not followed in 5e1361c (log: properly handle decorations with chained tags, 2013-12-17) Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-20log: properly handle decorations with chained tagsLibravatar brian m. carlson1-0/+15
git log did not correctly handle decorations when a tag object referenced another tag object that was no longer a ref, such as when the second tag was deleted. The commit would not be decorated correctly because parse_object had not been called on the second tag and therefore its tagged field had not been filled in, resulting in none of the tags being associated with the relevant commit. Call parse_object to fill in this field if it is absent so that the chain of tags can be dereferenced and the commit can be properly decorated. Include tests as well to prevent future regressions. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4205 (log-pretty-formats): avoid using `sed`Libravatar Alexey Shumkin1-16/+10
For testing truncated log messages 'commit_msg' function uses `sed` to cut a message. On various platforms `sed` behaves differently and results of its work depend on locales installed. So, avoid using `sed`. Use predefined expected outputs instead of calculated ones. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4205, t6006, t7102: make functions better readableLibravatar Alexey Shumkin1-1/+2
Function 'test_format' has become harder to read after its change in de6029a2 (pretty: Add failing tests: --format output should honor logOutputEncoding, 2013-06-26). Simplify it by moving its "should we expect it to fail?" parameter to the end. Note, current code does not use this last parameter as far as there are no tests expected to fail. We can keep that for future use. Also, reformat comments. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Improved-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4205 (log-pretty-formats): revert back single quotesLibravatar Alexey Shumkin1-53/+53
In previuos commit de6029a (pretty: Add failing tests: --format output should honor logOutputEncoding, 2013-06-26) single quotes were replaced with double quotes to make "$(commit_msg)" expression in heredoc to work. The same effect can be achieved by using "EOF" as a heredoc delimiter instead of "\EOF". Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Suggested-by: Johannes Sixt <j.sixt@viscovery.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1Libravatar Alexey Shumkin1-4/+4
Both "iso8859-1" and "iso-8859-1" are understood as latin-1 by modern platforms, but the latter is not understood by older platforms;update tests to use the former. This is in line with 3994e8a9 (t4201: use ISO8859-1 rather than ISO-8859-1, 2009-12-03), which did the same. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-01t4205: replace .\+ with ..* in sed commandsLibravatar Brian Gernhardt1-2/+2
OS X's sed only accepts basic regular expressions, which does not allow the + quantifier. However '..*' (anything, followed by zero or more anything) is the same as '.\+' (one or more anything) and valid in any regular expression language. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26pretty: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-17/+17
One can set an alias $ git config [--global] alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=local" to see the log as a pretty tree (like *gitk* but in a terminal). However, log messages written in an encoding i18n.commitEncoding which differs from terminal encoding are shown corrupted even when i18n.logOutputEncoding and terminal encoding are the same (e.g. log messages committed on a Cygwin box with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa). To simplify an example we can say the following two commands are expected to give the same output to a terminal: $ git log --oneline --no-color $ git log --pretty=format:'%h %s' However, the former pays attention to i18n.logOutputEncoding configuration, while the latter does not when it formats "%s". The same corruption is true for $ git diff --submodule=log and $ git rev-list --pretty=format:%s HEAD and $ git reset --hard This patch makes pretty --format honor logOutputEncoding when it formats log message. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26pretty: Add failing tests: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-56/+93
One can set an alias $ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset' --abbrev-commit --date=local" to see the log as a pretty tree (like *gitk* but in a terminal). However, log messages written in an encoding i18n.commitEncoding which differs from terminal encoding are shown corrupted even when i18n.logOutputEncoding and terminal encoding are the same (e.g. log messages committed on a Cygwin box with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa). To simplify an example we can say the following two commands are expected to give the same output to a terminal: $ git log --oneline --no-color $ git log --pretty=format:'%h %s' However, the former pays attention to i18n.logOutputEncoding configuration, while the latter does not when it formats "%s". The same corruption is true for $ git diff --submodule=log and $ git rev-list --pretty=format:%s HEAD and $ git reset --hard This patch adds failing tests for the next patch that fixes them. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-22/+26
The expected SHA-1 digests are always available in variables. Use them instead of hardcoding. Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18pretty: support %>> that steal trailing spacesLibravatar Nguyễn Thái Ngọc Duy1-0/+14
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-0/+39
%>(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/+122
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>
2012-10-17Fix "git diff --stat" for interesting - but empty - file changesLibravatar Linus Torvalds1-2/+2
The behavior of "git diff --stat" is rather odd for files that have zero lines of changes: it will discount them entirely unless they were renames. Which means that the stat output will simply not show files that only had "other" changes: they were created or deleted, or their mode was changed. Now, those changes do show up in the summary, but so do renames, so the diffstat logic is inconsistent. Why does it show renames with zero lines changed, but not mode changes or added files with zero lines changed? So change the logic to not check for "is_renamed", but for "is_interesting" instead, where "interesting" is judged to be any action but a pure data change (because a pure data change with zero data changed really isn't worth showing, if we ever get one in our diffpairs). So if you did chmod +x Makefile git diff --stat before, it would show empty (" 0 files changed"), with this it shows Makefile | 0 1 file changed, 0 insertions(+), 0 deletions(-) which I think is a more correct diffstat (and then with "--summary" it shows *what* the metadata change to Makefile was - this is completely consistent with our handling of renamed files). Side note: the old behavior was *really* odd. With no changes at all, "git diff --stat" output was empty. With just a chmod, it said "0 files changed". No way is our legacy behavior sane. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on diffstatLibravatar Jiang Xin1-2/+2
Use the i18n-specific test functions in test scripts for diffstat. This issue was was introduced in v1.7.9-1-g7f814: 7f814 Use correct grammar in diffstat summary line and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-01log-tree: the previous one is still not quite rightLibravatar Junio C Hamano1-0/+16
The correct output would have NUL after each commit, so "-z --format=%s" would have a single-liner subject with the line-terminating LF replaced with NUL, and "-p/--stat -z --format=%s" would have a single-liner subject with its line-terminating LF, followed by the diff/diffstat in which the terminating LF of the last line is replaced with NUL, but to be consistent with what "-p/--stat -z --pretty=format:%s" does, I think it is OK to append NUL to the diff/diffstat part instead of replacing its last LF with NUL. The added test shows the update is still not right for "-p -z --format". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-01log-tree: use custom line terminator in line termination modeLibravatar Jan Krüger1-0/+12
When using a custom format in line termination mode (as opposed to line separation mode), the configured line terminator is not used, so things like "git log --pretty=tformat:%H -z" do not work properly. Make it use the line terminator the user ordered. Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16Fix typo: existant->existentLibravatar Dmitry Ivankov1-1/+1
refs.c had a error message "Trying to write ref with nonexistant object". And no tests relied on the wrong spelling. Also typo was present in some test scripts internals, these tests still pass. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-03pretty: add aliases for pretty formatsLibravatar Will Palmer1-0/+74
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>