kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Alexey Shumkin	37eb772ef3	t4205 (log-pretty-formats): avoid using `sed` 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>	12 years ago
Alexey Shumkin	17cc2ef1c5	t4205, t6006, t7102: make functions better readable 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>	12 years ago
Alexey Shumkin	f3445f781f	t4205 (log-pretty-formats): revert back single quotes 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>	12 years ago
Alexey Shumkin	14332bccc1	t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1 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>	12 years ago
Brian Gernhardt	7c37521487	t4205: replace .\+ with ..* in sed commands 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>	12 years ago
Alexey Shumkin	ecaee8050c	pretty: --format output should honor logOutputEncoding 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>	12 years ago
Alexey Shumkin	de6029a2d7	pretty: Add failing tests: --format output should honor logOutputEncoding 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>	12 years ago
Alexey Shumkin	a742f2a0a7	t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs 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>	12 years ago
Nguyễn Thái Ngọc Duy	1640632b4f	pretty: support %>> that steal trailing spaces 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>	12 years ago
Nguyễn Thái Ngọc Duy	a7f01c6b4d	pretty: support truncating in %>, %< and %>< %>(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>	12 years ago
Nguyễn Thái Ngọc Duy	a57523428b	pretty: support padding placeholders, %< %> and %>< 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>	12 years ago
Linus Torvalds	74faaa16f0	Fix "git diff --stat" for interesting - but empty - file changes 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>	13 years ago
Jiang Xin	b354f11b59	Fix tests under GETTEXT_POISON on diffstat 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>	13 years ago
Junio C Hamano	fafd38299b	log-tree: the previous one is still not quite right 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>	13 years ago
Jan Krüger	3e065308ca	log-tree: use custom line terminator in line termination mode 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>	13 years ago
Dmitry Ivankov	7be8b3baba	Fix typo: existant->existent 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>	14 years ago
Will Palmer	8028184eec	pretty: add aliases for pretty formats 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>	15 years ago

17 Commits (c6f1b920ac8b41b9175910d5866924a12a0ce6b9)