summaryrefslogtreecommitdiff
path: root/t/t4202-log.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-10-09log --grep: use the same helper to set -E/-F options as "git grep"Libravatar Junio C Hamano1-0/+6
The command line option parser for "git log -F -E --grep='<ere>'" did not flip the "fixed" bit, violating the general "last option wins" principle among conflicting options. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'mz/cherry-pick-cmdline-order'Libravatar Junio C Hamano1-0/+10
"git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. * mz/cherry-pick-cmdline-order: cherry-pick/revert: respect order of revisions to pick demonstrate broken 'git cherry-pick three one two' teach log --no-walk=unsorted, which avoids sorting
2012-09-07Merge branch 'jc/dotdot-is-parent-directory'Libravatar Junio C Hamano1-0/+7
"git log .." errored out saying it is both rev range and a path when there is no disambiguating "--" is on the command line. Update the command line parser to interpret ".." as a path in such a case. * jc/dotdot-is-parent-directory: specifying ranges: we did not mean to make ".." an empty set
2012-08-30teach log --no-walk=unsorted, which avoids sortingLibravatar Martin von Zweigbergk1-0/+10
When 'git log' is passed the --no-walk option, no revision walk takes place, naturally. Perhaps somewhat surprisingly, however, the provided revisions still get sorted by commit date. So e.g 'git log --no-walk HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result (unless the two revisions share the commit date, in which case they will retain the order given on the command line). As the commit that introduced --no-walk (8e64006 (Teach revision machinery about --no-walk, 2007-07-24)) points out, the sorting is intentional, to allow things like git log --abbrev-commit --pretty=oneline --decorate --all --no-walk to show all refs in order by commit date. But there are also other cases where the sorting is not wanted, such as <command producing revisions in order> | git log --oneline --no-walk --stdin To accomodate both cases, leave the decision of whether or not to sort up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting to 'sorted' for backward-compatibility reasons. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on diffstatLibravatar Jiang Xin1-1/+1
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-08-23specifying ranges: we did not mean to make ".." an empty setLibravatar Junio C Hamano1-0/+7
Either end of revision range operator can be omitted to default to HEAD, as in "origin.." (what did I do since I forked) or "..origin" (what did they do since I forked). But the current parser interprets ".." as an empty range "HEAD..HEAD", and worse yet, because ".." does exist on the filesystem, we get this annoying output: $ cd Documentation/howto $ git log .. ;# give me recent commits that touch Documentation/ area. fatal: ambiguous argument '..': both revision and filename Use '--' to separate filenames from revisions Surely we could say "git log ../" or even "git log -- .." to disambiguate, but we shouldn't have to. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-30diff --stat: use less columns for change countsLibravatar Zbigniew Jędrzejewski-Szmek1-15/+15
Number of columns required for change counts is now computed based on the maximum number of changed lines instead of being fixed. This means that usually a few more columns will be available for the filenames and the graph. The graph width logic is also modified to include enough space for "Bin XXX -> YYY bytes". If changes to binary files are mixed with changes to text files, change counts are padded to take at least three columns. And the other way around, if change counts require more than three columns, then "Bin"s are padded to align with the change count. This way, the +- part starts in the same column as "XXX -> YYY" part for binary files. This makes the graph easier to parse visually thanks to the empty column. This mimics the layout of diff --stat before this change. Tests and the tutorial are updated to reflect the new --stat output. This means either the removal of extra padding and/or the addition of up to three extra characters to truncated filenames. One test is added to check the graph alignment when a binary file change and text file change of more than 999 lines are committed together. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-23Merge branch 'lp/maint-diff-three-dash-with-graph'Libravatar Junio C Hamano1-0/+290
"log -p --graph" used with "--stat" had a few formatting error. By Lucian Poston * lp/maint-diff-three-dash-with-graph: t4202: add test for "log --graph --stat -p" separator lines log --graph: fix break in graph lines log --graph --stat: three-dash separator should come after graph lines
2012-03-20t4202: add test for "log --graph --stat -p" separator linesLibravatar Lucian Poston1-0/+290
Add tests to make sure that the three-dash separator lines appear after the graph ancestry lines, and also the graph ancestry lines are not broken between the diffstat and the patch. Signed-off-by: Lucian Poston <lucian.poston@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-07merge: notice local merging of tags and keep it unwrappedLibravatar Junio C Hamano1-2/+2
This also updates the autogenerated merge title message from "merge commit X" to "merge tag X", and its effect can be seen in the changes to the test suite. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-18Add log.abbrevCommit config variableLibravatar Jay Soffian1-0/+53
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>
2010-12-08Merge branch 'jk/maint-decorate-01-bool'Libravatar Junio C Hamano1-0/+9
* jk/maint-decorate-01-bool: log.decorate: accept 0/1 bool values
2010-11-17log.decorate: accept 0/1 bool valuesLibravatar Jeff King1-0/+9
We explicitly document "0" and "1" as synonyms for "false" and "true" in boolean config options. However, we don't actually handle those values in git_config_maybe_bool. In most cases this works fine, as we call git_config_bool, which in turn calls git_config_bool_or_int, which in turn calls git_config_maybe_bool. Values of 0/1 are considered "not bool", but their integer values end up being converted to the corresponding boolean values. However, the log.decorate code looks for maybe_bool explicitly, so that it can fall back to the "short" and "full" strings. It does not handle 0/1 at all, and considers them invalid values. We cannot simply add 0/1 support to git_config_maybe_bool. That would confuse git_config_bool_or_int, which may want to distinguish the integer values "0" and "1" from bools. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-2/+2
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06t4202 (log): Replace '<git-command> || :' with test_might_failLibravatar Elijah Newren1-1/+1
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21Merge branch 'mm/shortopt-detached'Libravatar Junio C Hamano1-7/+12
* mm/shortopt-detached: log: parse separate option for --glob log: parse separate options like git log --grep foo diff: parse separate options --stat-width n, --stat-name-width n diff: split off a function for --stat-* option parsing diff: parse separate options like -S foo Conflicts: revision.c
2010-08-15log: test for regression introduced in v1.7.2-rc0~103^2~2Libravatar Ævar Arnfjörð Bjarmason1-1/+13
Add a regression test for the git log -M --follow $diff_option bug introduced in v1.7.2-rc0~103^2~2, $diff_option being diff related options like -p, --stat, --name-only etc. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06log: parse separate options like git log --grep fooLibravatar Matthieu Moy1-0/+7
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-06diff: parse separate options like -S fooLibravatar Matthieu Moy1-7/+5
Change the option parsing logic in revision.c to accept separate forms like `-S foo' in addition to `-Sfoo'. The rest of git already accepted this form, but revision.c still used its own option parsing. Short options affected are -S<string>, -l<num> and -O<orderfile>, for which an empty string wouldn't make sense, hence -<option> <arg> isn't ambiguous. This patch does not handle --stat-name-width and --stat-width, which are special-cases where diff_long_opt do not apply. They are handled in a separate patch to ease review. Original patch by Matthieu Moy, plus refactoring by Jonathan Nieder. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-08log.decorate: only ignore it under "log --pretty=raw"Libravatar Junio C Hamano1-28/+16
Unlike notes that are often multi-line and disrupting to be placed in many output formats, a decoration is designed to be a small token that can be tacked after an existing line of the output where a commit object name sits. Disabling log.decorate for something like "log --oneline" would defeat the purpose of the configuration. We _might_ want to change it further in the future to force scripts that do not want to be broken by random end user configurations to explicitly say "log --no-decorate", but that would be an incompatible change that needs the usual multi-release-cycle deprecation process. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-06log --pretty/--oneline: ignore log.decorateLibravatar Junio C Hamano1-16/+28
Many scripts, most notably gitk, rely on output from the log family of command not to be molested by random user configuration. This is especially true when --pretty=raw is given. Just like we disable notes output unless the command line explicitly asks for --show-notes, disable the decoration code unless --decorate is given explicitly from the command line and --pretty or --oneline is given. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17log.decorate: usability fixesLibravatar Junio C Hamano1-0/+49
The configuration is meant to suppliment --decorate command line option that can be used as a boolean to turn the feature on, so it is natural to expect [log] decorate decorate = yes to work. The original commit would segfault with the first one, and would not understand the second one. Once a user has this configuration in ~/.gitconfig, there needs to be a way to override it from the command line. Add --no-decorate option to log family and also allow --decorate=no to mean the same thing. Since we allow setting log.decorate to 'true', the command line also should accept --decorate=yes and behave accordingly. New tests in t4202 are designed to exercise the interaction between the configuration variable and the command line option that overrides it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26fix portability issues with $ in double quotesLibravatar Stephen Boyd1-3/+3
Using a dollar sign in double quotes isn't portable. Escape them with a backslash or replace the double quotes with single quotes. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-22strbuf_add_wrapped_text(): factor out strbuf_add_indented_text()Libravatar René Scharfe1-0/+21
Add a new helper function, strbuf_add_indented_text(), to indent text without a width limit, and call it from strbuf_add_wrapped_text(). It respects both indent (applied to the first line) and indent2 (applied to the rest of the lines); indent2 was ignored by the indent-only path of strbuf_add_wrapped_text() before the patch. Two simple test cases are added, one exercising strbuf_add_wrapped_text() and the other strbuf_add_indented_text(). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09merge: fix incorrect merge message for ambiguous tag/branchLibravatar Jeff King1-2/+2
If we have both a tag and a branch named "foo", then calling "git merge foo" will warn about the ambiguous ref, but merge the tag. When generating the commit message, though, we simply checked whether "refs/heads/foo" existed, and if it did, assumed it was a branch. This led to the statement "Merge branch 'foo'" in the commit message, which is quite wrong. Instead, we should use dwim_ref to find the actual ref used, and describe it appropriately. In addition to the test in t7608, we must also tweak the expected output of t4202, which was accidentally triggering this bug. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-18t4202-log.sh: Test git log --no-walk sort orderLibravatar Michael J Gruber1-0/+20
'git log --no-walk' sorts commits by commit time whereas 'git show' does not (it leaves them as given on the command line). Document this by two tests so that we never forget why ba1d450 (Tentative built-in "git show", 2006-04-15) introduced it and 8e64006 (Teach revision machinery about --no-walk, 2007-07-24) exposed it as an option argument. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-18Merge branch 'ac/graph-horizontal-line'Libravatar Junio C Hamano1-4/+2
* ac/graph-horizontal-line: graph API: Use horizontal lines for more compact graphs
2009-04-26t4202: fix typoLibravatar Linus Torvalds1-1/+1
While I did a make -j64 test > ~/t.out to check my previous patch (in case some test actually tested 'trustctime' or something), I noticed this one. Somebody has speeling trouble: t4202-log.sh: line 345: test_expect_sucess: command not found Fixed thus. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22graph API: Use horizontal lines for more compact graphsLibravatar Allan Caffee1-4/+2
Use horizontal lines instead of long diagonal lines during the collapsing state of graph rendering. For example what used to be: | | | | | | | | |/ | | |/| | |/| | |/| | | | | | | is now | | | | | | |_|_|/ |/| | | | | | | This results in more compact and legible graphs. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22graph API: fix a bug in the rendering of octopus mergesLibravatar Allan Caffee1-1/+1
An off by one error was causing octopus merges with 3 parents to not be rendered correctly. This regression was introduced by 427fc5. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-22t4202-log: extend test coverage of graphingLibravatar Allan Caffee1-2/+28
Extend this test to cover the rendering of graphs with octopus merges and pre_commit lines. Signed-off-by: Allan Caffee <allan.caffee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-11Merge branch 'tr/gcov'Libravatar Junio C Hamano1-0/+148
* tr/gcov: Test git-patch-id Test rev-list --parents/--children Test log --decorate Test fsck a bit harder Test log --graph Test diff --dirstat functionality Test that diff can read from stdin Support coverage testing with GCC/gcov
2009-02-25Add tests for git log --pretty, --format and --oneline.Libravatar Felipe Contreras1-0/+40
More specifically; --pretty=format, tformat and new %foo shortcut. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-20Test log --graphLibravatar Thomas Rast1-0/+148
So far there were no tests checking that log --graph actually works. Note that the tests strip trailing whitespace, as the current --graph emits trailing whitespace on lines that do not contain anything but graph lines. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-23t/t4202-log.sh: Add testcasesLibravatar Arjen Laarhoven1-9/+50
Add testcases for 'git log --diff-filter=[CM]' (copies and renames). Also add a testcase for 'git log --follow'. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-24Fix "git log -i --grep"Libravatar Jeff King1-0/+22
This has been broken in v1.6.0 due to the reorganization of the revision option parsing code. The "-i" is completely ignored, but works fine in "git log --grep -i". What happens is that the code for "-i" looks for revs->grep_filter; if it is NULL, we do nothing, since there are no grep filters. But that is obviously not correct, since we want it to influence the later --grep option. Doing it the other way around works, since "-i" just impacts the existing grep_filter option. Instead, we now always initialize the grep_filter member and just fill in options and patterns as we get them. This means that we can no longer check grep_filter for NULL, but instead must check the pattern list to see if we have any actual patterns. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23t/t4202-log.sh: add newline at end of fileLibravatar Brandon Casey1-1/+2
Some shells hang when parsing the script if the last statement is not followed by a newline. So add one. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-26Fix "git log --diff-filter" bugLibravatar Arjen Laarhoven1-0/+74
In commit b7bb760d5ed4881422673d32f869d140221d3564 (Fix revision log diff setup, avoid unnecessary diff generation) an optimization was made to avoid unnecessary diff generation. This was partly fixed in 99516e35d096f41e7133cacde8fbed8ee9a3ecd0 (Fix embarrassing "git log --follow" bug). The '--diff-filter' option also needs the diff machinery in action. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>