summaryrefslogtreecommitdiff
path: root/t/t4202-log.sh
AgeCommit message (Collapse)Author
2011-11-07merge: notice local merging of tags and keep it unwrappedJunio C Hamano
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 variableJay Soffian
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'Junio C Hamano
* jk/maint-decorate-01-bool: log.decorate: accept 0/1 bool values
2010-11-17log.decorate: accept 0/1 bool valuesJeff King
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 &&Jonathan Nieder
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_failElijah Newren
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-22Merge branch 'mm/shortopt-detached'Junio C Hamano
* 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-16log: test for regression introduced in v1.7.2-rc0~103^2~2Ævar Arnfjörð Bjarmason
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 fooMatthieu Moy
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 fooMatthieu Moy
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-09log.decorate: only ignore it under "log --pretty=raw"Junio C Hamano
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.decorateJunio C Hamano
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 fixesJunio C Hamano
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 quotesStephen Boyd
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-23strbuf_add_wrapped_text(): factor out strbuf_add_indented_text()René Scharfe
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/branchJeff King
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 orderMichael J Gruber
'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'Junio C Hamano
* ac/graph-horizontal-line: graph API: Use horizontal lines for more compact graphs
2009-04-26t4202: fix typov1.6.3-rc3Linus Torvalds
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-23graph API: Use horizontal lines for more compact graphsAllan Caffee
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-23graph API: fix a bug in the rendering of octopus mergesAllan Caffee
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-23t4202-log: extend test coverage of graphingAllan Caffee
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'Junio C Hamano
* 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.Felipe Contreras
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 --graphThomas Rast
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 testcasesArjen Laarhoven
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-25Fix "git log -i --grep"Jeff King
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 fileBrandon Casey
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" bugArjen Laarhoven
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>