summaryrefslogtreecommitdiff
path: root/t/t4205-log-pretty-formats.sh
AgeCommit message (Collapse)AuthorFilesLines
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-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>