summaryrefslogtreecommitdiff
path: root/t/t6006-rev-list-format.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-07-12rev-list: add option for --pretty=format without headerLibravatar brian m. carlson1-2/+78
In general, we encourage users to use plumbing commands, like git rev-list, over porcelain commands, like git log, when scripting. However, git rev-list has one glaring problem that prevents it from being used in certain cases: when --pretty is used with a custom format, it always prints out a line containing "commit" and the object ID. This makes it unsuitable for many scripting needs, and forces users to use git log instead. While we can't change this behavior for backwards compatibility, we can add an option to suppress this behavior, so let's do so, and call it "--no-commit-header". Additionally, add the corresponding positive option to switch it back on. Note that this option doesn't affect the built-in formats, only custom formats. This is exactly the same behavior as users already have from git log and is what most users will be used to. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t6[0-3]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-8/+8
Carefully excluding t6300, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t6[0-3]*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t6[0-3]*.sh && git checkout HEAD -- t6300\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-18t6006, t6012: adjust tests to use 'setup' instead of synonymsLibravatar Elijah Newren1-1/+1
With the new ability to pass --run=setup to select which tests to run, it is more convenient if tests use the term "setup" instead of synonyms like 'prepare' or 'rebuild'. There are undoubtedly many other tests in our testsuite that could be changed over too, these are just a couple that I ran into. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30t: remove test_oid_init in testsLibravatar brian m. carlson1-1/+0
Now that we call test_oid_init in the setup for all test scripts, there's no point in calling it individually. Remove all of the places where we've done so to help keep tests tidy. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-07t6006: make hash size independentLibravatar brian m. carlson1-1/+3
Instead of hard-coding the length of an object ID when creating a tree, compute it for the hash in use using the translation tables. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-30pretty: add "%aL" etc. to show local-part of email addressesLibravatar Prarit Bhargava1-2/+6
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>
2019-10-25t6006: use test-lib.sh definitionsLibravatar Prarit Bhargava1-10/+10
Use name and email definitions from test-lib.sh. Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t6006: simplify, fix, and optimize empty message testLibravatar Elijah Newren1-3/+2
Test t6006.71 ("oneline with empty message") was creating two commits with simple commit messages, and then running filter-branch to rewrite the commit messages to be "empty". This test was introduced in commit 1fb5fdd25f0 ("rev-list: fix --pretty=oneline with empty message", 2010-03-21) and written this way because the --allow-empty-message option to git commit did not exist at the time. However, the filter-branch invocation used differed slightly from --allow-empty-message in that it would have a commit message consisting solely of a single newline, and as such was not testing what the original commit intended to test. Since both a truly empty commit message and a commit message with a single linefeed could trigger the original bug, modify the test slightly to include an example of each. Despite only being one piece of the 71st test and there being 73 tests overall, this small change to just this one test speeds up the overall execution time of t6006 (as measured by the best of 3 runs of `time ./t6006-rev-list-format.sh`) by about 11% on Linux, 13% on Mac, and about 15% on Windows. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-11log: add %S option (like --source) to log --formatLibravatar Issac Trotts1-0/+4
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>
2018-05-14t: switch $_x40 to $OID_REGEXLibravatar brian m. carlson1-2/+2
Switch all uses of $_x40 to $OID_REGEX so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_x40/$OID_REGEX/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-17Revert "t6006: drop "always" color config tests"Libravatar Jeff King1-5/+15
This reverts commit c5bdfe677cfab5b2e87771c35565d44d3198efda. That commit was done primarily to prepare for the weakening of "always" in 6be4595edb (color: make "always" the same as "auto" in config, 2017-10-03). But since we've now reverted 6be4595edb, there's no need for us to remove "-c color.ui=always" from the tests. And in fact it's a good idea to restore these tests, to make sure that "always" continues to work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04t6006: drop "always" color config testsLibravatar Jeff King1-15/+5
We test the %C() format placeholders with a variety of color-inducing options, including "--color" and "-c color.ui=always". In preparation for the behavior of "always" changing, we need to do something with those "always" tests. We can drop ones that expect "always" to turn on color even to a file, as that will become a synonym for "auto", which is already tested. For the "--no-color" test, we need to make sure that color would otherwise be shown. To do this, we can use test_terminal, which enables colors in the default setup. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04test-terminal: set TERM=vt100Libravatar Jeff King1-2/+1
The point of the test-terminal script is to simulate in the test scripts an environment where output is going to a real terminal. But since test-lib.sh also sets TERM=dumb, the simulation isn't very realistic. The color code will skip auto-coloring for TERM=dumb, leading to us liberally sprinkling test_terminal env TERM=vt100 git ... through the test suite to convince the tests to actually generate colors. Let's set TERM for programs run under test_terminal, which is one less thing for test-writers to remember. In most cases the callers can be simplified, but note there is one interesting case in t4202. It uses test_terminal to check the auto-enabling of --decorate, but the expected output _doesn't_ contain colors (because TERM=dumb suppresses them). Using TERM=vt100 is closer to what the real world looks like; adjust the expected output to match. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13pretty: respect color settings for %C placeholdersLibravatar Jeff King1-34/+50
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>
2017-07-13rev-list: pass diffopt->use_colors through to pretty-printLibravatar Jeff King1-0/+11
When rev-list pretty-prints a commit, it creates a new pretty_print_context and copies items from the rev_info struct. We don't currently copy the "use_color" field, though. Nobody seems to have noticed because the only part of pretty.c that cares is the %C(auto,...) placeholder, and presumably not many people use that with the rev-list plumbing (as opposed to with git-log). It will become more noticeable in a future patch, though, when we start treating all user-format colors as auto-colors (in which case it would become impossible to format colors with rev-list, even with --color=always). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13t: use test_decode_color rather than literal ANSI codesLibravatar Jeff King1-16/+26
When we put literal ANSI terminal codes into our test scripts, it makes diffs on those scripts hard to read (the colors may be indistinguishable from diff coloring, or in the case of a reset, may not be visible at all). Some scripts get around this by including human-readable names and converting to literal codes with a git-config hack. This makes the actual code diffs look OK, but test_cmp output suffers from the same problem. Let's use test_decode_color instead, which turns the codes into obvious text tags. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-29pretty: avoid adding reset for %C(auto) if output is emptyLibravatar René Scharfe1-1/+1
We emit an escape sequence for resetting color and attribute for %C(auto) to make sure automatic coloring is displayed as intended. Stop doing that if the output strbuf is empty, i.e. when %C(auto) appears at the start of the format string, because then there is no need for a reset and we save a few bytes in the output. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-19pretty: let %C(auto) reset all attributesLibravatar René Scharfe1-1/+1
Reset colors and attributes upon %C(auto) to enable full automatic control over them; otherwise attributes like bold or reverse could still be in effect from previous %C placeholders. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-27format_commit_message: honor `color=auto` for `%C(auto)`Libravatar Edward Thomson1-7/+19
git-log(1) documents that when specifying the `%C(auto)` format placeholder will "turn on auto coloring on the next %placeholders until the color is switched again." However, when `%C(auto)` is used, the present implementation will turn colors on unconditionally (even if the color configuration is turned off for the current context - for example, `--no-color` was specified or the color is `auto` and the output is not a tty). Update `format_commit_one` to examine the current context when a format string of `%C(auto)` is specified, which ensures that we will not unconditionally write colors. This brings that behavior in line with the behavior of `%C(auto,<colorname>)`, and allows the user the ability to specify that color should be displayed only when the output is a tty. Additionally, add a test for `%C(auto)` and update the existing tests for `%C(auto,...)` as they were misidentified as being applicable to `%C(auto)`. Tests from Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: use verbose instead of hand-rolled errorsLibravatar Jeff King1-4/+1
Many tests that predate the "verbose" helper function use a pattern like: test ... || { echo ... false } to give more verbose output. Using the helper, we can do this with a single line, and avoid a || which interacts badly with &&-chaining (besides fooling --chain-lint, we hit the error block no matter which command in the chain failed, so we may often show useless results). In most cases, the messages printed by "verbose" are equally good (in some cases better; t6006 accidentally redirects the message to a file!). The exception is t7001, whose output suffers slightly. However, it's still enough to show the user which part failed, given that we will have just printed the test script to stderr. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-15tests: do not pass iso8859-1 encoded parameterLibravatar Pat Thoyts1-2/+2
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-07-09Merge branch 'jk/pretty-G-format-fixes'Libravatar Junio C Hamano1-0/+6
* jk/pretty-G-format-fixes: move "%G" format test from t7510 to t6006 pretty: avoid reading past end-of-string with "%G" t7510: check %G* pretty-format output t7510: test a commit signed by an unknown key t7510: use consistent &&-chains in loop t7510: stop referring to master in later tests
2014-06-25move "%G" format test from t7510 to t6006Libravatar Jeff King1-0/+6
The final test in t7510 checks that "--format" placeholders that look similar to GPG placeholders (but that we don't actually understand) are passed through. That test was placed in t7510, since the other GPG placeholder tests are there. However, it does not have a GPG prerequisite, because it is not actually checking any signed commits. This causes the test to erroneously fail when gpg is not installed on a system, however. Not because we need signed commits, but because we need _any_ commit to run "git log". If we don't have gpg installed, t7510 doesn't create any commits at all. We can fix this by moving the test into t6006. This is arguably a better place anyway, because it is where we test most of the other placeholders (we do not test GPG placeholders there because of the infrastructure needed to make signed commits). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21pretty.c: format string with truncate respects logOutputEncodingLibravatar Alexey Shumkin1-3/+3
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-2/+73
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-21t4041, t4205, t6006, t7102: don't hardcode tested encoding valueLibravatar Alexey Shumkin1-16/+19
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-03-19tests: use "env" to run commands with temporary env-var settingsLibravatar David Tran1-6/+3
Ordinarily, we would say "VAR=VAL command" to execute a tested command with environment variable(s) set only for that command. This however does not work if 'command' is a shell function (most notably 'test_must_fail'); the result of the assignment is retained and affects later commands. To avoid this, we used to assign and export environment variables and run such a test in a subshell, like so: ( VAR=VAL && export VAR && test_must_fail git command to be tested ) But with "env" utility, we should be able to say: test_must_fail env VAR=VAL git command to be tested which is much shorter and easier to read. Signed-off-by: David Tran <unsignedzero@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-05t6006 (rev-list-format): add tests for "%b" and "%s" for the case ↵Libravatar Alexey Shumkin1-13/+28
i18n.commitEncoding is not set In de6029a (pretty: Add failing tests: --format output should honor logOutputEncoding, 2013-06-26) 'complex-subject' test was changed. Revert it back, because that change actually removed tests for "%b" and "%s" with i18n.commitEncoding set. Also, add two more tests for mentioned above "%b" and "%s" to test encoding conversions with no i18n.commitEncoding set. 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-05t4205, t6006, t7102: make functions better readableLibravatar Alexey Shumkin1-20/+8
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-05t4041, t4205, t6006, t7102: use iso8859-1 rather than iso-8859-1Libravatar Alexey Shumkin1-7/+7
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-06-26pretty: --format output should honor logOutputEncodingLibravatar Alexey Shumkin1-4/+4
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-24/+59
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-26t6006 (rev-list-format): don't hardcode SHA-1 in expected outputsLibravatar Alexey Shumkin1-63/+77
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: two phase conversion for non utf-8 commitsLibravatar Nguyễn Thái Ngọc Duy1-6/+6
Always assume format_commit_item() takes an utf-8 string for string handling simplicity (we can handle utf-8 strings, but can't with other encodings). If commit message is in non-utf8, or output encoding is not, then the commit is first converted to utf-8, processed, then output converted to output encoding. This of course only works with encodings that are compatible with Unicode. This also fixes the iso8859-1 test in t6006. It's supposed to create an iso8859-1 commit, but the commit content in t6006 is in UTF-8. t6006 is now converted back in UTF-8 (the downside is we can't put utf-8 strings there anymore). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-17log --format: teach %C(auto,black) to respect color configLibravatar Junio C Hamano1-0/+55
Traditionally, %C(color attr) always emitted the ANSI color sequence; it was up to the scripts that wanted to conditionally color their output to omit %C(...) specifier when they do not want colors. Optionally allow "auto," to be prefixed to the color, so that the output is colored iff we would color regular "log" output (e.g., taking into account color.* and --color command line options). Tests and pretty_context bits by Jeff King <peff@peff.net>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-17t6006: clean up whitespaceLibravatar Junio C Hamano1-4/+4
The test_format function did not indent its in-line test script in an attempt to make the output of the test look better. But it does not make a big difference to the output, and the source looks quite ugly. Let's use our normal indenting instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-25Merge branch 'jk/ident-split-fix'Libravatar Junio C Hamano1-0/+7
An author/committer name that is a single character was mishandled as an invalid name by mistake.
2012-05-22fix off-by-one error in split_ident_lineLibravatar Jeff King1-0/+7
Commit 4b340cf split the logic to parse an ident line out of pretty.c's format_person_part. But in doing so, it accidentally introduced an off-by-one error that caused it to think that single-character names were invalid. This manifested itself as the "%an" format failing to show anything at all for a single-character name. Reported-by: Brian Turner <bturner@atlassian.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11tests: modernise style: more uses of test_line_countLibravatar Stefano Lattarini1-6/+7
Prefer: test_line_count <OP> COUNT FILE over: test $(wc -l <FILE) <OP> COUNT (or similar usages) in several tests. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-16pretty: give placeholders to reflog identityLibravatar Jeff King1-0/+6
When doing a reflog walk, you can get some information about the reflog (such as the subject line), but not the identity information (i.e., name and email). Let's make those available, mimicing the options for author and committer identity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13rev-list: handle %x00 NUL in user formatLibravatar Jeff King1-0/+8
The code paths for showing commits in "git log" and "git rev-list --graph" correctly handle embedded NULs by looking only at the resulting strbuf's length, and never treating it as a C string. The code path for regular rev-list, however, used printf("%s"), which resulted in truncated output. This patch uses fwrite instead, like the --graph code path. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-16pretty: Introduce ' ' modifier to add space if non-emptyLibravatar Michael J Gruber1-0/+10
We have the '+' modifiier which helps combine format specifiers which may possibly be empty, e.g. '%s%+b%n'. Introduce an analogous ' ' (space) modifier which adds a space before non-empty items. This helps assemble "one line type" format specifiers. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21Merge branch 'jn/shortlog'Libravatar Junio C Hamano1-0/+31
* jn/shortlog: pretty: Respect --abbrev option shortlog: Document and test --format option t4201 (shortlog): Test output format with multiple authors t4201 (shortlog): guard setup with test_expect_success Documentation/shortlog: scripted users should not rely on implicit HEAD
2010-05-08Merge branch 'eb/unpretty-b-format'Libravatar Junio C Hamano1-0/+9
* eb/unpretty-b-format: Add `%B' in format strings for raw commit body in `git log' and friends
2010-05-04pretty: Respect --abbrev optionLibravatar Will Palmer1-0/+31
Prior to this, the output of git log -1 --format=%h was always 7 characters long, without regard to whether --abbrev had been passed. Signed-off-by: Will Palmer <wmpalmer@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-17t6006: do not write to /tmpLibravatar Matthew Ogilvie1-1/+1
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-05Add `%B' in format strings for raw commit body in `git log' and friendsLibravatar Eli Barzilay1-0/+9
Also update the documentation text and add a test. Signed-off-by: Eli Barzilay <eli@barzilay.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-21rev-list: fix --pretty=oneline with empty messageLibravatar Erik Faye-Lund1-0/+9
55246aa (Dont use "<unknown>" for placeholders and suppress printing of empty user formats) introduced a check to prevent empty user-formats from being printed. This test didn't take empty commit messages into account, and prevented the line-termination from being output. This lead to multiple commits on a single line. Correct it by guarding the check with a check for user-format. A similar correction for the --graph code-path has been included. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>