summaryrefslogtreecommitdiff
path: root/t/t4202-log.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-05-15builtin/log: honor log.decorateLibravatar brian m. carlson1-0/+12
The recent change that introduced autodecorating of refs accidentally broke the ability of users to set log.decorate = false to override it. When the git_log_config was traversed a second time with an option other than log.decorate, the decoration style would be set to the automatic style, even if the user had already overridden it. Instead of setting the option in config parsing, set it in init_log_defaults instead. Add a test for this case. The actual additional config option doesn't matter, but it needs to be something not already set in the configuration file. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24log: if --decorate is not given, default to --decorate=autoLibravatar Alex Henrie1-1/+9
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-10Merge branch 'jk/log-graph-name-only'Libravatar Junio C Hamano1-0/+48
"git log --graph" did not work well with "--name-only", even though other forms of "diff" output were handled correctly. * jk/log-graph-name-only: diff: print line prefix for --name-only output
2017-02-08diff: print line prefix for --name-only outputLibravatar Jeff King1-0/+48
If you run "git log --graph --name-only", the pathnames are not indented to go along with their matching commits (unlike all of the other diff formats). We need to output the line prefix for each item before writing it. The tests cover both --name-status and --name-only. The former actually gets this right already, because it builds on the --raw format functions. It's only --name-only which uses its own code (and this fix mirrors the code in diff_flush_raw()). Note that the tests don't follow our usual style of setting up the "expect" output inside the test block. This matches the surrounding style, but more importantly it is easier to read: we don't have to worry about embedded single-quotes, and the leading indentation is more obvious. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-02Merge branch 'nd/log-graph-configurable-colors'Libravatar Junio C Hamano1-0/+22
Some people feel the default set of colors used by "git log --graph" rather limiting. A mechanism to customize the set of colors has been introduced. * nd/log-graph-configurable-colors: document behavior of empty color name color_parse_mem: allow empty color spec log --graph: customize the graph lines with config log.graphColors color.c: trim leading spaces in color_parse_mem() color.c: fix color_parse_mem() with value_len == 0
2017-01-31color_parse_mem: allow empty color specLibravatar Jeff King1-1/+1
Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23log --graph: customize the graph lines with config log.graphColorsLibravatar Nguyễn Thái Ngọc Duy1-0/+22
If you have a 256 colors terminal (or one with true color support), then the predefined 12 colors seem limited. On the other hand, you don't want to draw graph lines with every single color in this mode because the two colors could look extremely similar. This option allows you to hand pick the colors you want. Even with standard terminal, if your background color is neither black or white, then the graph line may match your background and become hidden. You can exclude your background color (or simply the colors you hate) with this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31graph: add support for --line-prefix on all graph-aware outputLibravatar Jacob Keller1-0/+323
Add an extension to git-diff and git-log (and any other graph-aware displayable output) such that "--line-prefix=<string>" will print the additional line-prefix on every line of output. To make this work, we have to fix a few bugs in the graph API that force graph_show_commit_msg to be used only when you have a valid graph. Additionally, we extend the default_diff_output_prefix handler to work even when no graph is enabled. This is somewhat of a hack on top of the graph API, but I think it should be acceptable here. This will be used by a future extension of submodule display which displays the submodule diff as the actual diff between the pre and post commit in the submodule project. Add some tests for both git-log and git-diff to ensure that the prefix is honored correctly. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10Merge branch 'jc/grep-commandline-vs-configuration' into maintLibravatar Junio C Hamano1-0/+14
"git -c grep.patternType=extended log --basic-regexp" misbehaved because the internal API to access the grep machinery was not designed well. * jc/grep-commandline-vs-configuration: grep: further simplify setting the pattern type
2016-08-04Merge branch 'jc/grep-commandline-vs-configuration'Libravatar Junio C Hamano1-0/+14
"git -c grep.patternType=extended log --basic-regexp" misbehaved because the internal API to access the grep machinery was not designed well. * jc/grep-commandline-vs-configuration: grep: further simplify setting the pattern type
2016-07-25grep: further simplify setting the pattern typeLibravatar Junio C Hamano1-0/+14
When c5c31d33 (grep: move pattern-type bits support to top-level grep.[ch], 2012-10-03) introduced grep_commit_pattern_type() helper function, the intention was to allow the users of grep API to having to fiddle only with .pattern_type_option (which can be set to "fixed", "basic", "extended", and "pcre"), and then immediately before compiling the pattern strings for use, call grep_commit_pattern_type() to have it prepare various bits in the grep_opt structure (like .fixed, .regflags, etc.). However, grep_set_pattern_type_option() helper function the grep API internally uses were left as an external function by mistake. This function shouldn't have been made callable by the users of the API. Later when the grep API was used in revision traversal machinery, the caller then mistakenly started calling the function around 34a4ae55 (log --grep: use the same helper to set -E/-F options as "git grep", 2012-10-03), instead of setting the .pattern_type_option field and letting the grep_commit_pattern_type() to take care of the details. This caused an unnecessary bug that made a configured grep.patternType take precedence over the command line options (e.g. --basic-regexp, --fixed-strings) in "git log" family of commands. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24log: add log.showSignature configuration variableLibravatar Mehul Jain1-0/+20
Users may want to always use "--show-signature" while using git-log and related commands. When log.showSignature is set to true, git-log and related commands will behave as if "--show-signature" was given to them. Note that this config variable is meant to affect git-log, git-show, git-whatchanged and git-reflog. Other commands like git-format-patch, git-rev-list are not to be affected by this config variable. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24log: add "--no-show-signature" command line optionLibravatar Mehul Jain1-0/+5
If an user creates an alias with "--show-signature" early in command line, e.g. [alias] logss = log --show-signature then there is no way to countermand it through command line. Teach git-log and related commands about "--no-show-signature" command line option. This will make "git logss --no-show-signature" run without showing GPG signature. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24t4202: refactor testLibravatar Mehul Jain1-2/+5
Subsequent patches will want to reuse the 'signed' branch that the 'log --graph --show-signature' test creates and uses. Split the set-up part into a test of its own, and make the existing test into a separate one that only inspects the history on the 'signed' branch. This way, it becomes clearer that tests added by subsequent patches reuse the 'signed' branch in the same way. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25diff: activate diff.renames by defaultLibravatar Matthieu Moy1-4/+4
Rename detection is a very convenient feature, and new users shouldn't have to dig in the documentation to benefit from it. Potential objections to activating rename detection are that it sometimes fail, and it is sometimes slow. But rename detection is already activated by default in several cases like "git status" and "git merge", so activating diff.renames does not fundamentally change the situation. When the rename detection fails, it now fails consistently between "git diff" and "git status". This setting does not affect plumbing commands, hence well-written scripts will not be affected. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28Merge branch 'jk/pending-keep-tag-name'Libravatar Junio C Hamano1-0/+29
History traversal with "git log --source" that starts with an annotated tag failed to report the tag as "source", due to an old regression in the command line parser back in v2.2 days. * jk/pending-keep-tag-name: revision.c: propagate tag names from pending array
2015-12-17revision.c: propagate tag names from pending arrayLibravatar Jeff King1-0/+29
When we unwrap a tag to find its commit for a traversal, we do not propagate the "name" field of the tag in the pending array (i.e., the ref name the user gave us in the first place) to the commit (instead, we use an empty string). This means that "git log --source" will never show the tag-name for commits we reach through it. This was broken in 2073949 (traverse_commit_list: support pending blobs/trees with paths, 2014-10-15). That commit tried to be careful and avoid propagating the path information for a tag (which would be nonsensical) to trees and blobs. But it should not have cut off the "name" field, which should carry forward to children. Note that this does mean that the "name" field will carry forward to blobs and trees, too. Whereas prior to 2073949, we always gave them an empty string. This is the right thing to do, but in practice no callers probably use it (since now we have an explicit separate "path" field, which was the point of 2073949). We add tests here not only for the broken case, but also a basic sanity test of "log --source" in general, which did not have any coverage in the test suite. Reported-by: Raymundo <gypark@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02Merge branch 'jk/log-missing-default-HEAD'Libravatar Junio C Hamano1-0/+14
"git init empty && git -C empty log" said "bad default revision 'HEAD'", which was found to be a bit confusing to new users. * jk/log-missing-default-HEAD: log: diagnose empty HEAD more clearly
2015-08-31log: diagnose empty HEAD more clearlyLibravatar Jeff King1-0/+14
If you init or clone an empty repository, the initial message from running "git log" is not very friendly: $ git init Initialized empty Git repository in /home/peff/foo/.git/ $ git log fatal: bad default revision 'HEAD' Let's detect this situation and write a more friendly message: $ git log fatal: your current branch 'master' does not have any commits yet We also detect the case that 'HEAD' points to a broken ref; this should be even less common, but is easy to see. Note that we do not diagnose all possible cases. We rely on resolve_ref, which means we do not get information about complex cases. E.g., "--default master" would use dwim_ref to find "refs/heads/master", but we notice only that "master" does not exist. Similarly, a complex sha1 expression like "--default HEAD^2" will not resolve as a ref. But that's OK. We fall back to a generic error message in those cases, and they are unlikely to be used anyway. Catching an empty or broken "HEAD" improves the common case, and the other cases are not regressed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-09log: add "log.follow" configuration variableLibravatar David Turner1-0/+23
People who work on projects with mostly linear history with frequent whole file renames may want to always use "git log --follow" when inspecting the life of the content that live in a single path. Teach the command to behave as if "--follow" was given from the command line when log.follow configuration variable is set *and* there is one (and only one) path on the command line. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-26Merge branch 'jk/test-chain-lint'Libravatar Junio C Hamano1-26/+6
People often forget to chain the commands in their test together with &&, leaving a failure from an earlier command in the test go unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to catch such a mistake more easily. * jk/test-chain-lint: (36 commits) t9001: drop save_confirm helper t0020: use test_* helpers instead of hand-rolled messages t: simplify loop exit-code status variables t: fix some trivial cases of ignored exit codes in loops t7701: fix ignored exit code inside loop t3305: fix ignored exit code inside loop t0020: fix ignored exit code inside loops perf-lib: fix ignored exit code inside loop t6039: fix broken && chain t9158, t9161: fix broken &&-chain in git-svn tests t9104: fix test for following larger parents t4104: drop hand-rolled error reporting t0005: fix broken &&-chains t7004: fix embedded single-quotes t0050: appease --chain-lint t9001: use test_when_finished t4117: use modern test_* helpers t6034: use modern test_* helpers t1301: use modern test_* helpers t0020: use modern test_* helpers ...
2015-03-25Merge branch 'dj/log-graph-with-no-walk'Libravatar Junio C Hamano1-0/+4
"git log --graph --no-walk A B..." is a otcnflicting request that asks nonsense; no-walk tells us show discrete points in the history, while graph asks to draw connections between these discrete points. Forbid the combination. * dj/log-graph-with-no-walk: revision: forbid combining --graph and --no-walk
2015-03-20t: use verbose instead of hand-rolled errorsLibravatar Jeff King1-25/+5
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 severe &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, in a location which causes a significant portion of the test to be missed (e.g., the test effectively does nothing, or consists of a long string of actions and output comparisons, and we throw away the exit code of at least one part of the string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-19revision: forbid combining --graph and --no-walkLibravatar Dongcan Jiang1-0/+4
Because "--graph" is about connected history while --no-walk is about discrete points, it does not make sense to allow these two options at the same time. [1] This change makes a few calls to "show --graph" fail in t4052, but asking to show one commit with graph is a nonsensical thing to do. Thus, tests on "show --graph" in t4052 have been removed [2,3]. Same tests on "show" without --graph option have already been tested in 4052. 3 testcases have been added to test this patch. [1]: http://article.gmane.org/gmane.comp.version-control.git/216083 [2]: http://article.gmane.org/gmane.comp.version-control.git/264950 [3]: http://article.gmane.org/gmane.comp.version-control.git/265107 Helped-By: Eric Sunshine <sunshine@sunshineco.com> Helped-By: René Scharfe <l.s.r@web.de> Helped-By: Junio C Hamano <gitster@pobox.com> Signed-off-by: Dongcan Jiang <dongcan.jiang@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-13log: teach --invert-grep optionLibravatar Christoph Junghans1-0/+15
"git log --grep=<string>" shows only commits with messages that match the given string, but sometimes it is useful to be able to show only commits that do *not* have certain messages (e.g. "show me ones that are not FIXUP commits"). Originally, we had the invert-grep flag in grep_opt, but because "git grep --invert-grep" does not make sense except in conjunction with "--files-with-matches", which is already covered by "--files-without-matches", it was moved it to revisions structure. To have the flag there expresses the function to the feature better. When the newly inserted two tests run, the history would have commits with messages "initial", "second", "third", "fourth", "fifth", "sixth" and "Second", committed in this order. The commits that does not match either "th" or "Sec" is "second" and "initial". For the case insensitive case only "initial" matches. Signed-off-by: Christoph Junghans <ottxor@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-09log: fix indentation for --graph --show-signatureLibravatar Zoltan Klinger1-0/+31
The git log --graph --show-signature command incorrectly indents the gpg information about signed commits and merged signed tags. It does not follow the level of indentation of the current commit. Example of garbled output: $ git log --show-signature --graph * commit 258e0a237cb69aaa587b0a4fb528bb0316b1b776 |\ gpg: Signature made Mon, Jun 30, 2014 13:22:33 EDT using RSA key ID DA08 gpg: Good signature from "Jason Pyeron <jpye...@pdinc.us>" Merge: 727c355 1ca13ed | | Author: Jason Pyeron <jpye...@pdinc.us> | | Date: Mon Jun 30 13:22:29 2014 -0400 | | | | Merge of 1ca13ed2271d60ba9 branch - rebranding | | | * commit 1ca13ed2271d60ba93d40bcc8db17ced8545f172 | | gpg: Signature made Mon, Jun 23, 2014 9:45:47 EDT using RSA key ID DD37 gpg: Good signature from "Stephen Robert Guglielmo <s...@guglielmo.us>" gpg: aka "Stephen Robert Guglielmo <srguglie...@gmail.com>" Author: Stephen R Guglielmo <s...@guglielmo.us> | | Date: Mon Jun 23 09:45:27 2014 -0400 | | | | Minor URL updates In log-tree.c modify show_sig_lines() function to call graph_show_oneline() after each line of gpg information it has printed in order to preserve the level of indentation for the next output line. Reported-by: Jason Pyeron <jpyeron@pdinc.us> Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-11Merge branch 'cb/log-follow-with-combined'Libravatar Junio C Hamano1-0/+14
* cb/log-follow-with-combined: fix segfault with git log -c --follow
2013-05-28fix segfault with git log -c --followLibravatar Clemens Buchacher1-0/+14
In diff_tree_combined we make a copy of diffopts. In try_to_follow_renames, called via diff_tree_sha1, we free and re-initialize diffopts->pathspec->items. Since we did not make a deep copy of diffopts in diff_tree_combined, the original diffopts does not get the update. By the time we return from diff_tree_combined, rev->diffopt->pathspec->items points to an invalid memory address. We get a segfault next time we try to access that pathspec. Instead, along with the copy of diffopts, make a copy pathspec->items as well. We would also have to make a copy of pathspec->raw to keep it consistent with pathspec->items, but nobody seems to rely on that. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-25t4202: use test_config/test_unconfig to set/unset git config variablesLibravatar Yann Droneaud1-20/+8
Instead of using construct such as: test_when_finished "git config --unset <key>" git config <key> <value> uses test_config <key> <value> The latter takes care of removing <key> at the end of the test. Additionally, instead of git config <key> "" or git config --unset <key> uses test_unconfig <key> The latter doesn't failed if <key> is not defined. Tests are modified to assume correct (default) configuration at entry, and to reset the modified configuration variables at the end. Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14Merge branch 'mk/maint-graph-infinity-loop' into maintLibravatar Junio C Hamano1-0/+10
* mk/maint-graph-infinity-loop: graph.c: infinite loop in git whatchanged --graph -m
2013-01-02Merge branch 'mk/maint-graph-infinity-loop'Libravatar Junio C Hamano1-0/+10
The --graph code fell into infinite loop when asked to do what the code did not expect. * mk/maint-graph-infinity-loop: graph.c: infinite loop in git whatchanged --graph -m
2012-11-09Merge branch 'js/format-2047'Libravatar Jeff King1-2/+2
Fixes many rfc2047 quoting issues in the output from format-patch. * js/format-2047: format-patch tests: check quoting/encoding in To: and Cc: headers format-patch: fix rfc2047 address encoding with respect to rfc822 specials format-patch: make rfc2047 encoding more strict format-patch: introduce helper function last_line_length() format-patch: do not wrap rfc2047 encoded headers too late format-patch: do not wrap non-rfc2047 headers too early utf8: fix off-by-one wrapping of text
2012-10-18utf8: fix off-by-one wrapping of textLibravatar Jan H. Schönherr1-2/+2
The wrapping logic in strbuf_add_wrapped_text() does currently not allow lines that entirely fill the allowed width, instead it wraps the line one character too early. For example, the text "This is the sixth commit." formatted via "%w(11,1,2)" (wrap at 11 characters, 1 char indent of first line, 2 char indent of following lines) results in four lines: " This is", " the", " sixth", " commit." This is wrong, because " the sixth" is exactly 11 characters long, and thus allowed. Fix this by allowing the (width+1) character of a line to be a valid wrapping point if it is a whitespace character. Signed-off-by: Jan H. Schönherr <schnhrr@cs.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-25graph.c: infinite loop in git whatchanged --graph -mLibravatar Michał Kiedrowicz1-0/+10
Running "whatchanged --graph -m" on a simple two-head merges can fall into infinite loop. Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 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>